Cumulative content of Working Group Meetings in 2023

Working Group Meeting

Date: 04/07/2023
Participants: Natalie Muric, Ansgar Mondorf, Eugen Costezki, Fred van Blommestein, Jostein Fromry, Peter, Pietro Palermo, Roschkowski Gregor, Wim Kok.
Model Editor: Andreea Pasăre
Note Editor: Jana Ahmad

Agenda:

Discuss ePO Glossary

Discussion

It was noted that the next steps of ePO development will be eAccess and ESPD models. It was mentioned that the data model in ESPD is represented using UML with non-specific relations between concepts.

During the meeting, the glossary for each module was presented. Each glossary contains all the related concepts, attributes, predicates (relations), and definitions. It was mentioned that when we have an external relation, it indicates a relation from an external module.

The alignment between PEPPOL business term requirements and ePO was also discussed. It was suggested to carry out this alignment during the Working Group Meetings, preferably every other Thursday, with a deadline set for the end of 2023.

To do this alignment, it was proposed to link ePO concepts that correspond to each BT, and the description of the BT would be the definition of the concept in ePO. It was clarified that a Business Term (BT) is the concept name in the business domain, while in ePO, it can refer to a concept, attribute, or predicate.

Examples from ePO were presented, such as the "Order" concept, which is a document with an identifier.

It was pointed out that to align concepts appropriately, the entire path of concepts should be mentioned, including inheritances. For example, the "Street Name" term should always be mapped to the street of an organization that is playing the agent in role.

The meeting also covered the issue date and issue time of an order. The dct:issued has a data type of rdfs:Literal which has been implemented as a xsd:dateTime datatype in ePO. rdfs:Literal includes xsd:dateTime.
During the meeting, it was noted that the ePO ontology, along with the glossary and documentation, will be published in the next couple of weeks.

Action Points

Alignment with PEPPOL business term requirements (suggested time line end 2023)

Working Group meeting

Date: 20/06/2023
Participants: Natalie Muric,
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Revise new eForms BTs in the extended Annex.

Discussion

The participants validated the new concepts in relation to the BTS found in the extended Annex of eForms. The BTs were mapped to the ePO ontology as follows, where the main bullet represents the BTs and the sub-bullets represent the corresponding ePO mapping:

BT-803: Notice Dispatch Date eSender
- epo:Notice epo:hasESenderDispatchDate in epo:Notice.
BT-738: Notice Preferred Publication Date
- epo:hasPreferredPublicationDate in epo:PublicationProvision
BT-578: Security Clearance
- epo:isSecurityClearanceRequired property was created in epo:SecurityClearanceTerm
BT-801: Non-Disclosure Agreement
- epo:NonDisclosureAgreementTerm class was created.
- epo:isNonDisclosureAgreementRequired:boolean property was created on epo:NonDisclosureAgreementTerm.
BT-802: Non-Disclosure Agreement Description
- dct:description on epo:NonDisclosureAgreementTerm concept.
BT-1371: Previous Planning Lot Identifier
- This BT refers to the identifier of the Lot in the current Notice. The mapping for this BT should be coupled with the mapping from BT-1251. We also need to add a link between epo:PlannedProcurementPart and the epo:ProcurementObject (by using epo:foreseesProcurementObject relation).
1251: Previous Planning Lot Identifier
- This refers to the identifier of the Previous PLannedProcurementPart; that will become the Lot from BT-1371.
- Example of Implementation in ePO: (it was noted, this can be implemented in other ways).
  - epo-not:CompetitionNotice epo:refersToPrevious epo-not:PlanningNotice. epo-not:PlanningNotice epo:announcesPlannedProcurementPart epo:PlannedProcurementPart. epo:PlannedProcurementPart adms:identifier adms:Identifier.

Definitions:

During the meeting, the participants validated the definitions of the following terms:

epo:hasPublicationDate: Date of formal public issuance of the document.
dct:issued: Date of formal issuance of the resource. Additional information: This is generally used for modules other than eNotice.

Action Point

Change back Lot Award Decision concept to Lot Award Outcome and also change back related relations.

Working Group meeting

Date: 13/06/2023
Participants: Natalie Muric, Giampaolo Sellitto
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda:

Revise all Monetary Values with respect to Framework Agreement.

Discussion:

The participants validated the monetary values in relation to the BTs in the extended Annex of eForms. The BTs were mapped to the ePO ontology as follows, where the main bullet represents the BTs and the sub-bullets represent the corresponding ePO mapping:

BT-27: Framework Maximum Value
- epo:FrameworkAgreementTerm epo:hasLaunchFrameworkAgreementMaximumValue epo:MonetaryValue
BT-157: Group Framework Maximum Value
- epo:FrameworkAgreementTerm epo:hasLaunchGroupFrameworkAgreementMaximumValue epo:MonetaryValue
- epo:hasEstimatedValue was changed to epo:hasLaunchGroupFrameworkAgreementMaximumValue
BT-644: Prize Value
- epo:Prize po:hasPrizeValue / epo:hasAmountValue epo:MonetaryValue .
BT-161: Notice Value
- epo:NoticeAwardInformation epo:hasTotalAwardedValue epo:MonetaryValue
BT-118: Notice Framework Maximum Value
- epo:NoticeAwardInformation epo:hasTotalAwardedValue epo:MonetaryValue
BT-1118: Notice Framework Approximate Value
- epo:NoticeAwardInformation epo:hasApproximateFrameworkAgreementValue epo:MonetaryValue
BT-156: Group Framework Re-calculated Maximum Value
- epo:LotGroupAwardInformation epo:hasGroupFrameworkAgreementMaximumValue epo:MonetaryValue
- epo:hasGroupFrameworkAgreementAwardedValue was changed to epo:hasGroupFrameworkAgreementMaximumValue
BT-1561: Group Framework Re-estimated Value
- epo:LotGroupAwardInformation epo:hasApproximateGroupFrameworkAgreementValue epo:MonetaryValue
BT-709: Framework Re-calculated Maximum Value
- epo:LotAwardDecision epo:hasFrameworkAgreementMaximumValue epo:MonetaryValue
BT-660: Framework Re-estimated Value
- epo:LotAwardDecision epo:hasApproximateFrameworkAgreementValue epo:MonetaryValue
- epo:hasFrameworkAgreementEstimatedValue was changed to epo:hasApproximateFrameworkAgreementValue
BT-710: Tender Value Lowest
- epo:SubmissionStatisticalInformation epo:hasLowestReceivedTenderValue epo:MonetaryValue
BT-711: Tender Value Highest
- epo:SubmissionStatisticalInformation epo:hasHighestReceivedTenderValue epo:MonetaryValue
BT-720: Tender Value
- epo:Tender epo:hasFinancialOfferValue epo:MonetaryValue
BT-779: Tender Payment Value
- epo:ContractLotCompletionInformation epo:providesContractTotalPaymentValue epo:MonetaryValue
BT-782: Tender Penalties
- epo:ContractLotCompletionInformation epo:providesContractTotalPenaltyValue epo:MonetaryValue
BT-162: Concession Revenue User
- epo:ConcessionEstimate epo:hasEstimatedUserConcessionRevenue epo:MonetaryValue
BT-160: Concession Revenue Buyer
- epo:ConcessionEstimate epo:hasEstimatedBuyerConcessionRevenue epo:MonetaryValue
BT-553: Subcontracting Value
- epo:SubcontractingEstimate epo:hasSubcontractingEstimatedValue epo:MonetaryValue
BT-793: Review Remedy Value
- epo:ReviewDecision epo:hasRemedyValue epo:MonetaryValue
BT-795: Review Request Fee
- epo:ReviewRequest epo:hasReviewRequestFee epo:MonetaryValue
- epo:paidReviewRequestFee was changed to epo:hasReviewRequestFee

Working Group meeting

Date: 01/06/2023
Participants: Natalie Muric, Glan Luigi Albano, Giovanna Filippone, Goncalo Negrao, Martina Pititto, Paolo De Lazzaro, Peter, Thomas Pettersson
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda:

ePO module harmonisation
Discuss eContract model

Discussion:

ePO module harmonisation

It was noted that the models had become easier to work with after the changes made during the previous post-award meeting. In the updated models, each line can now have a description and specify an item. The Information Hub has a direct link to the line, and the AllowanceChargeInformation could be defined at both the Document and Line levels.

The participants then discussed modeling virtual locations for service deliveries it was decided to use location based on coordinates, indicating a geographical location where the delivery could take place.
It was noted after the WGM that a virtual delivery location should be represented as a URL and further discussion is needed on this matter.

CC8AAACZqQkvUYwvceVLPvFf1o0xy2eK0UV4AQAAmLLwUlX8gGeMWX4DAACw2gkvxpixDQAAwGo31eEFAAAAYDkTXgAAAADGRHgBAAAAGBPhBQAAAGBMhBcAAACAMRFeAAAAAMZEeAEAAAAYE+EFAAAAYEyEFwAAAIAxEV4AAAAAxkR4AQAAABgT4QUAAABgTIQXAAAAgDERXgAAAADGRHgBAAAAGBPhBQAAAGBMhBcAAACAMRFeAAAAAMZEeAEAAAAYE+EFAAAAYEyEFwAAAIAxEV4AAAAAxkR4AQAAABiTWngxxhhjjDHGGGOMMaOb6P8HHHC3FlIgQ14AAAAASUVORK5CYII=

Contract

The Contract model was presented whereby a Contract is a Document and is subject to Contract Terms. It is signed by both the Contractor and the Buyer(s). It has reference to the Lot(s).
The contract model requirements were mapped to the ePO ontology as follows, where the main bullet represents the requirement, and the sub-bullets represent the corresponding ePO mapping:

Contract
- epo:Contract
Contract identifier
- epo:Contract adms:identifier adms:identifier
Contract issue date:
- Dct:issued in epo:Document
Contract issue time
- Dct:issued in epo:Document
Contract type
- At-voc:contract-nature codelist. But it was noted that, it does not cover for FA or DPS needs to be checked. Also, Reference number of the contract needs to be checked.
Process control
- In the meeting, it was noted that Process control is not applicable in data-oriented modelling (ePO)
Contracting body
- epo:Buyer
Economic operator
- epo:Contractor
Procurement project name
- Dct:title on epo:Contract
Procurement project description
- Dct:description on epo:Contract
Procurement project type
- uses contract-nature on ContractTerms
Estimated total value
- is at the ProcurementObject level.
Description of extension and options:
- epo:hasOptionsDescription on ContractTerms
CPV
- at-voc:cpv codelist at Contract level
CPV
- supplementary is not included in ePO
Procurement project location NUTS code
epo:ContractTerm epo:definesPlaceOfPerformance dct:Location
dct:Location epo:hasNutsCode at-voc:nuts
Period start date
- epo:ContractTerm epo:definesContractPeriod epo:Period
Period start time
- epo:ContractTerm epo:definesContractPeriod epo:Period
Period end date
- epo:ContractTerm epo:definesContractPeriod epo:Period
Period end time
- epo:ContractTerm epo:definesContractPeriod epo:Period
Lot identifier
- epo:Contract epo:hasLotReference epo:Lot
Award criterion type
- epo:Lot epo:specifiesProcurementCriterion epo:AwardCriterion epo:hasAwardCriterionType at-voc:award-criterion-type
Legal references
- epo:Lot epo:hasLegalBasis at-voc:legal-basis OR epo:hasLegalBasisDescription on epo:ProcurementObject
Tender identifier
- epo:Contract epo:includesTender epo:Tender
Tender digest
- epo:hasElectronicDigest
Tender signature
- epo:hasElectronicSignature
Tender total amount:
- epo:Tender epo:hasFinancialOfferValue epo:MonetaryValue
Tender total taxes amount:
- epo:Tender epo:hasTaxInformation epo-ord:TaxInformation epo-cat:hasAmount
- It was noted a conflict in the definitions of Tender total taxes amount and Tender total amount in the in contract model requirements.
  - Tender total amount: The total amount of the offered deliverables in the tender excluding all taxes payable by the contracting authority.
  - Tender total taxes amount: The total amount of taxes included in the total amount.
Award identifier:
- epo:AwardDecision adms:identifier adms:Identifier
Award date
- epo:hasAwardDecisionDate (by using xsd:dateTime attribute)
Award time
- epo:hasAwardDecisionDate (by using xsd:dateTime attribute)
Winner economic operator
- epo:Winner
Economic operator name
- dct:title on the foaf:Agent
Economic operator identifier:
- adms:identifier on the foaf:Agent
Economic operator registration country code:
- org:Organization epo:hasRegistrationCountry at-voc:country.
Documents:
- epo:Document epo:associatedWith epo:Document
- epo:Contract is an epo:Document
Attachment identifier:
- adms:identifier on epo:Document
Attachment description:
- dct:description on epo:Document
Attached document
- We do not provide the binary object, only URL (epo:hasAccessURL on the epo:Document)
Deliverable offered
- epo:Contract epo:specifiesDeliverable epo:Item
Deliverable name
- dct:title on the epo:Item
Deliverable description
- dct:description on the epo:Item
Delivered quantity
- epo:Deliverable epo-cat:hasQuantity epo:Quantity
Deliverable total amount
- epo:Deliverable epo:hasTotalValue epo:MonetaryValue The model below was validated.

The property epo:hasAccessURL has been removed from the Contract class because it was inherited from the Document class.
The property epo:hasHomePage was changed to epo:hasInternetAddress in cpov:ContactPoint class.
It was noted that epo:hasInternetAddress is used in various places

cpov:ContactPoint epo:hasInternetAddress
Org: Organization epo:hasInternetAddress
Org: Organization epo:hasPrimaryContactPoint cpov:ContactPoint The epo:hasInternetAddress was defined:
epo:hasInternetAddress: The main webpage used by the instance of the concept.
It was noted that the Contract class needs to have its own estimated value, as it is not considered a Procurement Element. This is to distinguish between the Tender value and the Contract value. As a result, the Contract now includes the relation epo:hasContractValue to capture the value associated with the contract. This property is linked to the epo:MonetaryValue class. Additionally, the Contract has a lot reference through the property "epo:hasLotReference" which connects it to the epo:Lot class.
Further discussion is needed to determine how to model Monetary Values with respect to both Contract and Tender.

The Contract class has an Amended Contract subclass. The Amended Contract class inherits all attributes from the Contract class.

The following Notices were discussed, and it was suggested to update the Notice modules accordingly to implement them.

Contract Completion Notice Announcement of the completion of a contract The main purpose of this notice is to understand if the contract was completed as set out in the contract award notice (to be published on 2023-06-14 in EU Vocabularies) It was noted that the Completion Notice announces the completion of the Contract, not the Contract itself. Therefore: epo:announcesContract was changed to epo:announcesCompletionOfContract.
Pre-Market Consultation Notice Announcement of a pre-market consultation. A pre-market consultation is not a call for competition, and no procurement documents are available at the time of consultation. A consultation may or may not be followed by a future competition (to be published 2023-06-14 in EU Vocabularies).

Action Points

Points to be followed up
- What is the Reference number of the contract
- The conflict in the definitions of Tender total taxes amount and Tender total amount needs to be addressed.
  - Tender total amount: The total amount of the offered deliverables in the tender excluding all taxes payable by the contracting authority.
  - Tender total taxes amount: The total amount of taxes included in the total amount.
- Contract type is mapped to at-voc:contract-nature codelist (works, service and supplies) in ePO. However in the contract model requirements contract type can also be FA and DPS it should be checked if there is a valid reason for this?
- Update the Notice modules to implement Contract Completion Notice and Pre-Market Consultation Notice.

Agenda

Continue discussing Dynamic Purchasing System (DPS) model
Relations and properties definition harmonisation.
epo-cat:hasAmount
epo:hasValidityPeriod
dct:title
skos:prefLabel
dct:Description

Discussion

During the WGM meeting, the modeling of Award Decisions within the Framework Agreement and Dynamic Purchasing System (DPS) ontology following the previous meeting. Based on this discussion, the following updates were made:

epo:announcesLotAwardOutcome was changed to epo:announcesLotAwardDecision.
epo:ResultNotice epo:announcesLotAwardDecision epo:AwardDecision should be visible in Notice module
epo:comprisesLotAwardOutcome was changed to epo:comprisesLotAwardDecision

The participants defined the following terms and relations:

epo:SubmissionStatisticalInformation: Statistical information about submissions on a given competition, either at Lot level or Mini-Competition level.
epo:MiniCompetitionAwardDecision: Result concerning the Mini-Competition attributed by the Awarder
epo:summarisesInformationForAwardDecision: Relates to submission for the given competition, either at Lot level or Mini-Competition level.

The model below was validated:

Framework Agreement

The participants reviewed and validated the following model:

A Framework Agreement results from a Lot Award Decision, which concerns a specific Lot that uses the framework technique. The Lot Award decision which is used to establish the Framework Agreement specifies the different Qualification Criterion and Award Criterion (Procurement Criterion) to be used. The Mini Competition that may be launched within the Framework Agreement follows the rules set by the Framework Agreement and involves specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.
During the meeting, it was confirmed that technique is used at lot level.
The relation epo:indicatesAwardOfLotToWinner was changed to epo:indicatesAwardToWinner to accommodate the award of mini-competitions.
Furthermore, the participants defined the following terms:
epo:MiniCompetition: A process where multiple winners or candidates of previous stages of a procedure bid for a specific procurement. Additional Information:
It is typically used in framework agreements where the suppliers have already been pre-selected, and the mini competition is used to determine which supplier is best suited for a particular project or contract. It is also used in a Dynamic Purchasing System where the suppliers come from a list of Candidates.
epo:QualificationCriterion: Criterion used in the first stage of procurement.
epo:ParticipationCondition: Criterion that describes a Requirement to take part in a procurement.

DPS:

The DPS diagram below was reviewed and validated by the participants:

A DPS (Dynamic Purchasing System) uses a DPS Technique. In the first stage, the different Qualification Criterion are specified and there is no Award Decision, however a Candidate List is created which lists the economic operators that are admitted to subsequent Mini-Competitions. The subsequent Mini Competitions involve specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.

During the WGM, a question was raised regarding whether "epo:DynamicPurchasingSystem" should be a subclass of "epo:system." The decision was to leave it for the time being and if the need became apparent this would be implemented.

Additionally, epo:CandidateList was changed to epo:SelectedCandidateList and its definition is updated to the following definition: Record of Candidates admitted to take part in award phases of procurements.
epo:Candidate: The Role of an Agent that has sought an invitation or has been invited to take part in a restricted Procedure, in a competitive Procedure with negotiation, in a negotiated Procedure without prior publication, in a competitive dialogue or in an innovation partnership.

Relation and property definition harmonisation.

The following relations and properties occur in the ontology with more than one definition the participants therefore agreed on a common definition for each
epo-cat:hasAmount: The predetermined monetary value charged in addition to the price.

epo:hasValidityPeriod: The relation indicating until when a given instance of a concept is applicable.
epo:hasCertification: Relation to the proof of conformance.
dct:description: An account of the resource. Additional Information: Description may include, but is not limited to: an abstract, a table of contents, a graphical representation, or a free-text account of the resource.
dct:title: A name given to the resource.
skos:prefLabel: The preferred lexical label for a resource, in a given language. (it has been added as issue into GitHub)
For the relation epo-cat:has Amount one of the relations had a definition and the others not so the one existing definition was pasted in all: The predetermined monetary value charged in addition to the price. After meeting note: however this definition should be further reviewed.

Action
Add the following changes to the ticket titled "Review changes that affect the standard form mappings."

epo:announcesLotAwardOutcome was changed to epo:announcesLotAwardDecision.
epo:comprisesLotAwardOutcome was changed to epo:comprisesLotAwardDecision
epo:indicatesAwardOfLotToWinner was changed to epo:indicatesAwardToWinner.

Working Group meeting 23/05/2023

Date: 23/05/2023
Participants: Natalie Muric, Giovanna Filippone, Martina Pititto, Giampaolo Sellitto
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Discuss Dynamic Purchasing System (DPS) model
Is there an actual Award Decision in the DPS after the Qualification Stage, even if there is no Contract Award Notice?

Discussion

The WGM started by introducing the participants to the scope of the ePO ontology, which aims to provide a formal representation of the concepts, relationships, and entities within the eProcurement domain. It aims to facilitate the exchange of procurement-related information between different systems and organizations, and to support the automation and optimization of procurement processes. The ontology covers various aspects of procurement, such as procurement notification, tendering, contracting, and invoicing and is data oriented.
The modeling of Framework Agreement and Dynamic Purchasing System (DPS) within the ontology was presented.

Framework Agreement

A Framework Agreement results from a Lot Award Decision, which concerns a specific Lot that uses the framework technique. The Lot Award decision which is used to establish the Framework Agreement specifies the different Qualification Criterion and Award Criterion (Procurement Criterion) to be used. The Mini Competition that may be launched within the Framework Agreement follows the rules set by the Framework Agreement and involves specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.
The model below was validated:

DPS

A DPS (Dynamic Purchasing System) uses a DPS Technique. In the first stage, the different Qualification Criterion are specified and there is no Award Decision, however a Candidate List is created which lists the economic operators that are admitted to subsequent Mini-Competitions. The subsequent Mini Competitions involves specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.
The model below was validated:

Award Decision:

To ensure Award Decisions exist for both the Framework Agreement and the Mini Competitions the Award Decision has become a superclass of Lot Award Decision and Mini Competition Award Decision allowing for the different instantiations required for different use cases. The Award Decision comprises Tender Award Outcome which indicates award of Lot to a winner. These relations are inherited by the Lot Award Decision and Mini Competition Award Decision. See diagram below.

After meeting note: as the Mini Competition inherits from the Award Decision the relation “indicatesAwardOfLotToWinner” needs to be reviewed maybe to “indicatesAwardToWinner”
During the WGM, the relations describesLot and describesMiniCompetition were changed to concernsLot and concernsMiniCompetition respectively. Additionally, the relations, epo:hasRestated AwardedValue and epo:hasRestatedEstimatedValue were removed from the model.

Definitions:

During the meeting, the participants defined the following terms:

epo:hasBargainPrice: The value of procured supplies that have used a particularly advantageous opportunity available for a very short time at a value considerably lower than normal market prices.
DPS: An electronic System that is set up by a Buyer which lists the Economic Operators that satisfy the Qualification Criteria, which may later be put into competition via a Mini-Competition in view of awarding a Purchase Contract.
DynamicPurchaseSystemTechniqueUsage: A Technique that allows the selection of Candidates throughout the Procedure via the Qualification Criteria, followed by individual Mini-Competitions for the Award of Purchase Contracts.
ListCanditate: A list of Candidates considered to take part in a restricted Procedure, in a competitive Procedure with negotiation, in a negotiated Procedure without prior publication, in a competitive dialogue or in an innovation partnership.

Action points:

Include the changes made to the "epo:hasRestatedAwardedValue" and "epo:hasRestatedEstimatedValue" relations in the ticket titled "Review changes that affect the standard form mappings."

Working Group meeting 16/05/2023

Date: 16/05/2023
Participants: Natalie Muric, Pietro Palermo, Peter Borresen, Thomas Pettersson.
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Harmonization of modules for eCatalogue, eFulfilment, and eOrdering Modules

Charge Information - Item Level or Line Level?
Item and Batch IDs
Organisation and Person Certificates
Remodelling epo-ord:DeliveryTerm

Discussion

The working group began by reviewing previous agreements related to eCatalogue, eOrdering, and eFulfilment modules reached in meetings held on April 25, 27, and May 3, 2023.The participants confirmed their consensus on the proposed changes.

Removal of epo-cat:hasExternalSpecification property in the epo-cat:item in Catalogue module
Standardised namespace prefix for ePO Model (Note: in the text and diagrams in this report the standardised namespace of epo: has not been used as the standardized namespace is to implemented with all other changes.)
Renaming epo-cat:ItemDescription to epo:ItemProperty.
Replacing epo-ful:hasBaseAmount property with epo:isCalculatedOn in epo-ord:AllowanceChargeInformation and epo-ord:TaxInformation . Replace epo-cat:specifiesItem relationship between epo:Deliverable and epo-cat:Item by inheritance of epo-cat:Item by epo:Deliverable.
epo:Contractor and epo-ord:Seller are the same concepts in a Public Procurement.
epo-ord:AllowanceChargeInformation will have 3 subclasses: epo-ord:AllowanceInformation, epo-ord:ChargeInformation, and epo-ord:PriceDiscountInformation, because epo-ord:AllowanceChargeInformation is an epo-cat:InformationHub, and it is directly connected to the Line and Document.
The VAT rate value will be modeled through epo-ord:TaxInformation epo-cat:hasPercentage and epo-ord:TaxInformation epo-cat:hasTaxCategory. The working group then continued to discuss the points that were seen as contentious previously:

Charge Information - Item Level or Line Level?

During the discussion, participants debated whether the Charge Information should be at the Item level or Line level. To illustrate the point an example of countries where certain charges are associated with food items containing sugar. For instance, if an item is priced at 1 euro, the actual amount paid might be 1.7 euros due to the sugar charge. This charge is applied at the price level.
One suggestion put forward was to have the price at the item level, establishing a direct association between the item and its price. However, after further deliberation, the decision was made to maintain the price at the line level while establishing a reference between the line and the item.

In PEPPOL the price is specified based on the location, and the order reflects the price based on quantities. There are two types of discounts: line-level discounts and price-level discounts. Line-level discounts can be defined as a specific amount per line, such as a discount of 100 euros per line. Price-level discounts, on the other hand, are expressed as a certain amount per unit, such as cents per orange.
As a result of the discussion, it was decided to remove the epo-ord:PriceDiscountInformation element and introduce new associations for enhanced clarity and consistency. The new associations are epo-ord:hasPriceDiscountInformation between epo-cat:Price and epo-ord:isSpecificToOrderLine, as well epo:hasPriceSurchargeInformation between epo-cat:Price and epo-cat:ChargeInformation.

Modeling of Item and Batch IDs

The participants agreed to replace the relation adms:identifier with epo:hasBatchID to improv clarity and consistency. The epo: hasCatalogueItemID is replaced by epo:hasSellerItemID
As part of the discussion, it was agreed to add definitions for all epo:Item and epo:Batch IDs:

epo:hasManufacturerItemID: The general identifier assigned to the concept as defined by the manufacturer.
epo:hasBuyerItemID: The general identifier assigned to the concept as defined by the Buyer.
epo:hasBatchID: The identifier assigned to a specific batch of the produced Item.
epo:hasSellerItemID: The general identifier for the concept as defined by the seller.
epo:hasSerialID: The identifier assigned to the specific instance of the produced concept.

To illustrate these concepts, an example was discussed: when purchasing a new mobile phone, the seller ID and the manufacturer ID may differ, but a generic buyer ID would be used.
Organisation and Person Certificates
It was agreed upon by the participants to introduce the epo:hasCertification relation between epo:Certificate and epo:Organization, epo:Person, and epo:Item. This new relation allows for the association of certifications with these entities.
Furthermore, the definitions for the following concepts were updated as follows:

epo:Certifier: A Role of an Agent that issues a Certificate.
epo:Certificate: Proof of conformance of the instance of the concept to a defined set of criteria, ensuring credibility, trust and transparency.

Remodelling epo-ord:DeliveryTerm

During the working group meeting, it was agreed by the participants to rename the entity epo-ord:DeliveryTerm to epo-ord:DeliveryAgreement. By changing the name of the concept there is no conflict with the Term hierarchy of the ontology and the original modelling can be reused. The update was made directly in the meeting.
.

Dt6P7F1hhjhgYAgMUgfAEAANjUhC8AAACbmvAFAABgUxO+AAAAbGrCFwAAgE1N+AIAALCpCV8AAAA2NeELAADApiZ8AQAA2NSELwAAAJua8AUAAGBTE74AAABsasIXAACATU34AgAAsKkJXwAAADY14QsAAMCmJnwBAADY1IQvAAAAm5rwBQAAYFMTvgAAAGxqwhcAAIBNTfgCAACwqQlfAAAANrUkfI0xxhhjjDHGmM020f8H9pztfcNmz7AAAAAASUVORK5CYII=

Revising Definitions

The participants revised the definitions with respect to the concepts that were discussed during the meeting.

epo-ord:DeliveryAgreement: Term applying to the delivery of goods, services and works. Additional Information: Delivery terms identifier can normally be Incoterms accompanied by the description of specific conditions related to the delivery.
epo-cat:InformationHub: Grouping of data that may be associated to various concepts. Additional Information: For example, AllowanceChargeInformation may be associated to the Order or the Catalogue (either at the Line level or at the Document level), amongst others.
epo-cat:ChargeInformation: Information about tax, fee or duty imposed. Additional Information: Charge category indicates the nature of the tax/duty/fee, for example VAT, CAR, etc. Charge category modifier may be used in case different levels, exemptions or other modifications apply. The charge can be fixed or relative to the price.
epo-ord:AllowanceChargeInformation: Information about discounts, taxes, duties and fees imposed.
epo-ord:AllowanceInformation: Information about the discounts imposed.

Action Points:

Remove epo-ord:PriceDiscountInformation and introduce new associations:
epo-cat:Price epo-ord:hasPriceDiscountInformation epo-ord:isSpecificToOrderLine
epo-cat:Price epo:hasPriceSurchargeInformation epo-cat:ChargeInformation.
Update definitions for all epo:Item and epo:Batch IDs
Organisation and Person Certificates:
Update the definition of epo:Certifier and epo:Certificate.
Introduce new associations:
epo:Person epo:hasCertification epo:Certificate
org:Organization epo:hasCertification epo:Certificate
epo:Item epo:hasCertification epo:Certificate

Working Group meeting

Date: 01/08/2023
Participants: Natalie Muric, Arillo Aranda Paloma, Pascaline Laure Tchienehom
Model editor: Andreea Pasăre
Note editor: Alexandros Vassiliades

Agenda:

Present first draft of eAccess module

Discussion:

Can we consider the ESPD Business Handbook (ESPD Request part only) as requirements for eAccess?
- https://wiki.ds.unipi.gr/display/ESPDInt/BIS+41+-+ESPD+V2.1.0#BIS41ESPDV2.1.0-tbr070-007
Discuss the following statement: It is not necessary for Buyers and Economic Operators to create a new ESPD document for each procedure. Instead, it is possible to re-use an ESPD in different procurement procedures, facilitating the tasks of users.

Reuse in the previous sentence also implies partial reuse of the content in the xml file. Paloma will change the previous sentence in order to reflect the actual meaning more accurately.

Requirements of ESPD and the eAccess should not be considered the same. We should

A new property from ESPDResponse to ESPDRequest was created (epo-sub:relatesToESPDRequest):

The Lot is defined at the ESPDResponse level as depicted in the image below:

Though it is not sure that the ESPDRequest can be related to more than one Procedures. It was implicitly agreed that each ESPDRequest will have its own Procedure since an ESPDRequest will have its own identifier for each Procedure.
Going through the attributes from ESPDRequest concept in ESPD model:
- ReferenceNumber does not need to be covered in ePO
- DocumentVersionIdentifier exists as epo:hasVersion at the Document level in ePO
- Discussion over the various types of dates that exist on the ESPD class:
  - An ESPD is published and not issued
  - In ePO we have epo:hasPublicationDate at the Document level, but the data type do not allow us to also store the time, only the date; and for an ESPD we need both date and time
- CopyIndicator should be removed but is still in the UML diagram of ESPD. This concept does not seem to be needed in ePO also.
The relation between epo:ESPDRequest and epo:Buyer seems an overkill as they are related through the epo:Procedure, and it was removed.
We need to provide an identifier for Criteria, so this means that cccev:Requirement should be connected through a relation (adms:identifier) with adms:Identifier. But CCCEV provides identifiers as a literal attribute on the concepts. Added an action point to discuss whether we can reuse CCCEV and ADMS concepts like this.
epo:ProcurementCriterion was connected by relation epo-acc:implementsLegislation with epo-acc:Legislation and by relation epo-acc:implementsArticle with epo-acc:Article.
The legislation part for Criterion is implemented as depicted in the image below:

qYOAFwKX28AAPEQigDWXPjGDgBcCV9vAADxEIoAAAAAgABCEQAAAAAQsC6bTgkAAAAAgCpCEQAAAAAQ8Br0lIoPhhNj2AAAAABJRU5ErkJggg==

Action point:

Discuss on the need to change epo:hasPublicationDate on epo:Document
Check if the cccev:InformationConcept and adms:Identifier can be connected between them. Because here we have a concept from an ontology A (cccev:InformationConcept) and a concept through an ontology B (adms:Identifier), connected between them. Same case for cccev:Requirement and adms:identifier

jUghLaIepu8efkCYiIaTWql6Yv6f1GE0MbWuISYaL21fxMIoc3a+Mb5DoKYO2njPw6EUFAb3zjfQRATIYRIg5gIIUQaxEQIIdIgJkIIkQYxEUKINIiJEEKkQUyEECINYiKEEGkQEyGESIOYCCFEGsRECCHSICZCCJH2g1g0jxBCiCSIiRBCpEFMhBAiDWIihBBpEBMhhEiDmAghRBrERAgh0iAmQgiRBjERQog0iIkQQqRBTIQQIg1iIoQQaRATIYRIg5gIIUQaxEQIIdIgJkIIkQYxEUKItB8WhHMIIYRIgpgIIUQaxEQIIdIgJkIIkQYxEUKINIiJEEKkQUyEECINYiKEEGkQEyGESIOYCCFEGsRECCHSICZCCJEGMRFCiDSIiRBCpEFMhBAiDWIihBBpEBMhhEj7QSSYRQghRBLERAgh0iAmQgiRBjERQog0iIkQQqRBTIQQIg1iIoQQaRATIYRIg5gIIUQaxEQIIdIgJkIIkQYxEUKINIiJEEKkQUyEECINYiKEEGkQEyGESIOYCCFE2g+i+RmEEEIkQUyEECINYiKEEGkQEyGESIOYCCFEGsRECCHSICZCCJEGMRFCiDSIiRBCpEFMhBAiDWIihBBpEBMhhEiDmAghRBrERAgh0iAmQgiR9v8BLm6oAI5ctEsAAAAASUVORK5CYII=

Working Group meeting

Date: 13/06/2023
Participants: Natalie Muric, Giampaolo Sellitto
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda:

Revise all Monetary Values with respect to Framework Agreement.

Discussion:

The participants validated the monetary values in relation to the BTs in the extended Annex of eForms. The BTs were mapped to the ePO ontology as follows, where the main bullet represents the BTs and the sub-bullets represent the corresponding ePO mapping:

BT-27: Framework Maximum Value
- epo:FrameworkAgreementTerm epo:hasLaunchFrameworkAgreementMaximumValue epo:MonetaryValue
BT-157: Group Framework Maximum Value
- epo:FrameworkAgreementTerm epo:hasLaunchGroupFrameworkAgreementMaximumValue epo:MonetaryValue
- epo:hasEstimatedValue was changed to epo:hasLaunchGroupFrameworkAgreementMaximumValue
BT-644: Prize Value
- epo:Prize po:hasPrizeValue / epo:hasAmountValue epo:MonetaryValue .
BT-161: Notice Value
- epo:NoticeAwardInformation epo:hasTotalAwardedValue epo:MonetaryValue
BT-118: Notice Framework Maximum Value
- epo:NoticeAwardInformation epo:hasTotalAwardedValue epo:MonetaryValue
BT-1118: Notice Framework Approximate Value
- epo:NoticeAwardInformation epo:hasApproximateFrameworkAgreementValue epo:MonetaryValue
BT-156: Group Framework Re-calculated Maximum Value
- epo:LotGroupAwardInformation epo:hasGroupFrameworkAgreementMaximumValue epo:MonetaryValue
- epo:hasGroupFrameworkAgreementAwardedValue was changed to epo:hasGroupFrameworkAgreementMaximumValue
BT-1561: Group Framework Re-estimated Value
- epo:LotGroupAwardInformation epo:hasApproximateGroupFrameworkAgreementValue epo:MonetaryValue
BT-709: Framework Re-calculated Maximum Value
- epo:LotAwardDecision epo:hasFrameworkAgreementMaximumValue epo:MonetaryValue
BT-660: Framework Re-estimated Value
- epo:LotAwardDecision epo:hasApproximateFrameworkAgreementValue epo:MonetaryValue
- epo:hasFrameworkAgreementEstimatedValue was changed to epo:hasApproximateFrameworkAgreementValue
BT-710: Tender Value Lowest
- epo:SubmissionStatisticalInformation epo:hasLowestReceivedTenderValue epo:MonetaryValue
BT-711: Tender Value Highest
- epo:SubmissionStatisticalInformation epo:hasHighestReceivedTenderValue epo:MonetaryValue
BT-720: Tender Value
- epo:Tender epo:hasFinancialOfferValue epo:MonetaryValue
BT-779: Tender Payment Value
- epo:ContractLotCompletionInformation epo:providesContractTotalPaymentValue epo:MonetaryValue
BT-782: Tender Penalties
- epo:ContractLotCompletionInformation epo:providesContractTotalPenaltyValue epo:MonetaryValue
BT-162: Concession Revenue User
- epo:ConcessionEstimate epo:hasEstimatedUserConcessionRevenue epo:MonetaryValue
BT-160: Concession Revenue Buyer
- epo:ConcessionEstimate epo:hasEstimatedBuyerConcessionRevenue epo:MonetaryValue
BT-553: Subcontracting Value
- epo:SubcontractingEstimate epo:hasSubcontractingEstimatedValue epo:MonetaryValue
BT-793: Review Remedy Value
- epo:ReviewDecision epo:hasRemedyValue epo:MonetaryValue
BT-795: Review Request Fee
- epo:ReviewRequest epo:hasReviewRequestFee epo:MonetaryValue
- epo:paidReviewRequestFee was changed to epo:hasReviewRequestFee

Working Group meeting

Date: 01/06/2023
Participants: Natalie Muric, Glan Luigi Albano, Giovanna Filippone, Goncalo Negrao, Martina Pititto, Paolo De Lazzaro, Peter, Thomas Pettersson
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda:

ePO module harmonisation
Discuss eContract model

Discussion:

ePO module harmonisation

It was noted that the models had become easier to work with after the changes made during the previous post-award meeting. In the updated models, each line can now have a description and specify an item. The Information Hub has a direct link to the line, and the AllowanceChargeInformation could be defined at both the Document and Line levels.

The participants then discussed modeling virtual locations for service deliveries it was decided to use location based on coordinates, indicating a geographical location where the delivery could take place.
It was noted after the WGM that a virtual delivery location should be represented as a URL and further discussion is needed on this matter.

Contract

The Contract model was presented whereby a Contract is a Document and is subject to Contract Terms. It is signed by both the Contractor and the Buyer(s). It has reference to the Lot(s).
The contract model requirements were mapped to the ePO ontology as follows, where the main bullet represents the requirement, and the sub-bullets represent the corresponding ePO mapping:

Contract
- epo:Contract
Contract identifier
- epo:Contract adms:identifier adms:identifier
Contract issue date:
- Dct:issued in epo:Document
Contract issue time
- Dct:issued in epo:Document
Contract type
- At-voc:contract-nature codelist. But it was noted that, it does not cover for FA or DPS needs to be checked. Also, Reference number of the contract needs to be checked.
Process control
- In the meeting, it was noted that Process control is not applicable in data-oriented modelling (ePO)
Contracting body
- epo:Buyer
Economic operator
- epo:Contractor
Procurement project name
- Dct:title on epo:Contract
Procurement project description
- Dct:description on epo:Contract
Procurement project type
- uses contract-nature on ContractTerms
Estimated total value
- is at the ProcurementObject level.
Description of extension and options:
- epo:hasOptionsDescription on ContractTerms
CPV
- at-voc:cpv codelist at Contract level
CPV
- supplementary is not included in ePO
Procurement project location NUTS code
epo:ContractTerm epo:definesPlaceOfPerformance dct:Location
dct:Location epo:hasNutsCode at-voc:nuts
Period start date
- epo:ContractTerm epo:definesContractPeriod epo:Period
Period start time
- epo:ContractTerm epo:definesContractPeriod epo:Period
Period end date
- epo:ContractTerm epo:definesContractPeriod epo:Period
Period end time
- epo:ContractTerm epo:definesContractPeriod epo:Period
Lot identifier
- epo:Contract epo:hasLotReference epo:Lot
Award criterion type
- epo:Lot epo:specifiesProcurementCriterion epo:AwardCriterion epo:hasAwardCriterionType at-voc:award-criterion-type
Legal references
- epo:Lot epo:hasLegalBasis at-voc:legal-basis OR epo:hasLegalBasisDescription on epo:ProcurementObject
Tender identifier
- epo:Contract epo:includesTender epo:Tender
Tender digest
- epo:hasElectronicDigest
Tender signature
- epo:hasElectronicSignature
Tender total amount:
- epo:Tender epo:hasFinancialOfferValue epo:MonetaryValue
Tender total taxes amount:
- epo:Tender epo:hasTaxInformation epo-ord:TaxInformation epo-cat:hasAmount
- It was noted a conflict in the definitions of Tender total taxes amount and Tender total amount in the in contract model requirements.
  - Tender total amount: The total amount of the offered deliverables in the tender excluding all taxes payable by the contracting authority.
  - Tender total taxes amount: The total amount of taxes included in the total amount.
Award identifier:
- epo:AwardDecision adms:identifier adms:Identifier
Award date
- epo:hasAwardDecisionDate (by using xsd:dateTime attribute)
Award time
- epo:hasAwardDecisionDate (by using xsd:dateTime attribute)
Winner economic operator
- epo:Winner
Economic operator name
- dct:title on the foaf:Agent
Economic operator identifier:
- adms:identifier on the foaf:Agent
Economic operator registration country code:
- org:Organization epo:hasRegistrationCountry at-voc:country.
Documents:
- epo:Document epo:associatedWith epo:Document
- epo:Contract is an epo:Document
Attachment identifier:
- adms:identifier on epo:Document
Attachment description:
- dct:description on epo:Document
Attached document
- We do not provide the binary object, only URL (epo:hasAccessURL on the epo:Document)
Deliverable offered
- epo:Contract epo:specifiesDeliverable epo:Item
Deliverable name
- dct:title on the epo:Item
Deliverable description
- dct:description on the epo:Item
Delivered quantity
- epo:Deliverable epo-cat:hasQuantity epo:Quantity
Deliverable total amount
- epo:Deliverable epo:hasTotalValue epo:MonetaryValue The model below was validated.

The property epo:hasAccessURL has been removed from the Contract class because it was inherited from the Document class.
The property epo:hasHomePage was changed to epo:hasInternetAddress in cpov:ContactPoint class.
It was noted that epo:hasInternetAddress is used in various places

cpov:ContactPoint epo:hasInternetAddress
Org: Organization epo:hasInternetAddress
Org: Organization epo:hasPrimaryContactPoint cpov:ContactPoint The epo:hasInternetAddress was defined:
epo:hasInternetAddress: The main webpage used by the instance of the concept.
It was noted that the Contract class needs to have its own estimated value, as it is not considered a Procurement Element. This is to distinguish between the Tender value and the Contract value. As a result, the Contract now includes the relation epo:hasContractValue to capture the value associated with the contract. This property is linked to the epo:MonetaryValue class. Additionally, the Contract has a lot reference through the property "epo:hasLotReference" which connects it to the epo:Lot class.
Further discussion is needed to determine how to model Monetary Values with respect to both Contract and Tender.

The Contract class has an Amended Contract subclass. The Amended Contract class inherits all attributes from the Contract class.

The following Notices were discussed, and it was suggested to update the Notice modules accordingly to implement them.

Contract Completion Notice Announcement of the completion of a contract The main purpose of this notice is to understand if the contract was completed as set out in the contract award notice (to be published on 2023-06-14 in EU Vocabularies) It was noted that the Completion Notice announces the completion of the Contract, not the Contract itself. Therefore: epo:announcesContract was changed to epo:announcesCompletionOfContract.
Pre-Market Consultation Notice Announcement of a pre-market consultation. A pre-market consultation is not a call for competition, and no procurement documents are available at the time of consultation. A consultation may or may not be followed by a future competition (to be published 2023-06-14 in EU Vocabularies).

Action Points

Points to be followed up
- What is the Reference number of the contract
- The conflict in the definitions of Tender total taxes amount and Tender total amount needs to be addressed.
  - Tender total amount: The total amount of the offered deliverables in the tender excluding all taxes payable by the contracting authority.
  - Tender total taxes amount: The total amount of taxes included in the total amount.
- Contract type is mapped to at-voc:contract-nature codelist (works, service and supplies) in ePO. However in the contract model requirements contract type can also be FA and DPS it should be checked if there is a valid reason for this?
- Update the Notice modules to implement Contract Completion Notice and Pre-Market Consultation Notice.

Agenda

Continue discussing Dynamic Purchasing System (DPS) model
Relations and properties definition harmonisation.
epo-cat:hasAmount
epo:hasValidityPeriod
dct:title
skos:prefLabel
dct:Description

Discussion

During the WGM meeting, the modeling of Award Decisions within the Framework Agreement and Dynamic Purchasing System (DPS) ontology following the previous meeting. Based on this discussion, the following updates were made:

epo:announcesLotAwardOutcome was changed to epo:announcesLotAwardDecision.
epo:ResultNotice epo:announcesLotAwardDecision epo:AwardDecision should be visible in Notice module
epo:comprisesLotAwardOutcome was changed to epo:comprisesLotAwardDecision

The participants defined the following terms and relations:

epo:SubmissionStatisticalInformation: Statistical information about submissions on a given competition, either at Lot level or Mini-Competition level.
epo:MiniCompetitionAwardDecision: Result concerning the Mini-Competition attributed by the Awarder
epo:summarisesInformationForAwardDecision: Relates to submission for the given competition, either at Lot level or Mini-Competition level.

The model below was validated:

Framework Agreement

The participants reviewed and validated the following model:

A Framework Agreement results from a Lot Award Decision, which concerns a specific Lot that uses the framework technique. The Lot Award decision which is used to establish the Framework Agreement specifies the different Qualification Criterion and Award Criterion (Procurement Criterion) to be used. The Mini Competition that may be launched within the Framework Agreement follows the rules set by the Framework Agreement and involves specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.
During the meeting, it was confirmed that technique is used at lot level.
The relation epo:indicatesAwardOfLotToWinner was changed to epo:indicatesAwardToWinner to accommodate the award of mini-competitions.
Furthermore, the participants defined the following terms:
epo:MiniCompetition: A process where multiple winners or candidates of previous stages of a procedure bid for a specific procurement. Additional Information:
It is typically used in framework agreements where the suppliers have already been pre-selected, and the mini competition is used to determine which supplier is best suited for a particular project or contract. It is also used in a Dynamic Purchasing System where the suppliers come from a list of Candidates.
epo:QualificationCriterion: Criterion used in the first stage of procurement.
epo:ParticipationCondition: Criterion that describes a Requirement to take part in a procurement.

DPS:

The DPS diagram below was reviewed and validated by the participants:

A DPS (Dynamic Purchasing System) uses a DPS Technique. In the first stage, the different Qualification Criterion are specified and there is no Award Decision, however a Candidate List is created which lists the economic operators that are admitted to subsequent Mini-Competitions. The subsequent Mini Competitions involve specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.

During the WGM, a question was raised regarding whether "epo:DynamicPurchasingSystem" should be a subclass of "epo:system." The decision was to leave it for the time being and if the need became apparent this would be implemented.

Additionally, epo:CandidateList was changed to epo:SelectedCandidateList and its definition is updated to the following definition: Record of Candidates admitted to take part in award phases of procurements.
epo:Candidate: The Role of an Agent that has sought an invitation or has been invited to take part in a restricted Procedure, in a competitive Procedure with negotiation, in a negotiated Procedure without prior publication, in a competitive dialogue or in an innovation partnership.

Relation and property definition harmonisation.

The following relations and properties occur in the ontology with more than one definition the participants therefore agreed on a common definition for each
epo-cat:hasAmount: The predetermined monetary value charged in addition to the price.

epo:hasValidityPeriod: The relation indicating until when a given instance of a concept is applicable.
epo:hasCertification: Relation to the proof of conformance.
dct:description: An account of the resource. Additional Information: Description may include, but is not limited to: an abstract, a table of contents, a graphical representation, or a free-text account of the resource.
dct:title: A name given to the resource.
skos:prefLabel: The preferred lexical label for a resource, in a given language. (it has been added as issue into GitHub)
For the relation epo-cat:has Amount one of the relations had a definition and the others not so the one existing definition was pasted in all: The predetermined monetary value charged in addition to the price. After meeting note: however this definition should be further reviewed.

Action
Add the following changes to the ticket titled "Review changes that affect the standard form mappings."

epo:announcesLotAwardOutcome was changed to epo:announcesLotAwardDecision.
epo:comprisesLotAwardOutcome was changed to epo:comprisesLotAwardDecision
epo:indicatesAwardOfLotToWinner was changed to epo:indicatesAwardToWinner.

Working Group meeting 23/05/2023

Date: 23/05/2023
Participants: Natalie Muric, Giovanna Filippone, Martina Pititto, Giampaolo Sellitto
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Discuss Dynamic Purchasing System (DPS) model
Is there an actual Award Decision in the DPS after the Qualification Stage, even if there is no Contract Award Notice?

Discussion

The WGM started by introducing the participants to the scope of the ePO ontology, which aims to provide a formal representation of the concepts, relationships, and entities within the eProcurement domain. It aims to facilitate the exchange of procurement-related information between different systems and organizations, and to support the automation and optimization of procurement processes. The ontology covers various aspects of procurement, such as procurement notification, tendering, contracting, and invoicing and is data oriented.
The modeling of Framework Agreement and Dynamic Purchasing System (DPS) within the ontology was presented.

Framework Agreement

A Framework Agreement results from a Lot Award Decision, which concerns a specific Lot that uses the framework technique. The Lot Award decision which is used to establish the Framework Agreement specifies the different Qualification Criterion and Award Criterion (Procurement Criterion) to be used. The Mini Competition that may be launched within the Framework Agreement follows the rules set by the Framework Agreement and involves specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.
The model below was validated:

DPS

A DPS (Dynamic Purchasing System) uses a DPS Technique. In the first stage, the different Qualification Criterion are specified and there is no Award Decision, however a Candidate List is created which lists the economic operators that are admitted to subsequent Mini-Competitions. The subsequent Mini Competitions involves specifying the different Award Criterion to be used. The Mini Competition Award Decision relates to the Mini Competition itself and can result in a Purchase Contract.
The model below was validated:

Award Decision:

To ensure Award Decisions exist for both the Framework Agreement and the Mini Competitions the Award Decision has become a superclass of Lot Award Decision and Mini Competition Award Decision allowing for the different instantiations required for different use cases. The Award Decision comprises Tender Award Outcome which indicates award of Lot to a winner. These relations are inherited by the Lot Award Decision and Mini Competition Award Decision. See diagram below.

After meeting note: as the Mini Competition inherits from the Award Decision the relation “indicatesAwardOfLotToWinner” needs to be reviewed maybe to “indicatesAwardToWinner”
During the WGM, the relations describesLot and describesMiniCompetition were changed to concernsLot and concernsMiniCompetition respectively. Additionally, the relations, epo:hasRestated AwardedValue and epo:hasRestatedEstimatedValue were removed from the model.

Definitions:

During the meeting, the participants defined the following terms:

epo:hasBargainPrice: The value of procured supplies that have used a particularly advantageous opportunity available for a very short time at a value considerably lower than normal market prices.
DPS: An electronic System that is set up by a Buyer which lists the Economic Operators that satisfy the Qualification Criteria, which may later be put into competition via a Mini-Competition in view of awarding a Purchase Contract.
DynamicPurchaseSystemTechniqueUsage: A Technique that allows the selection of Candidates throughout the Procedure via the Qualification Criteria, followed by individual Mini-Competitions for the Award of Purchase Contracts.
ListCanditate: A list of Candidates considered to take part in a restricted Procedure, in a competitive Procedure with negotiation, in a negotiated Procedure without prior publication, in a competitive dialogue or in an innovation partnership.

Action points:

Include the changes made to the "epo:hasRestatedAwardedValue" and "epo:hasRestatedEstimatedValue" relations in the ticket titled "Review changes that affect the standard form mappings."

Working Group meeting 16/05/2023

Date: 16/05/2023
Participants: Natalie Muric, Pietro Palermo, Peter Borresen, Thomas Pettersson.
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Harmonization of modules for eCatalogue, eFulfilment, and eOrdering Modules

Charge Information - Item Level or Line Level?
Item and Batch IDs
Organisation and Person Certificates
Remodelling epo-ord:DeliveryTerm

Discussion

The working group began by reviewing previous agreements related to eCatalogue, eOrdering, and eFulfilment modules reached in meetings held on April 25, 27, and May 3, 2023.The participants confirmed their consensus on the proposed changes.

Removal of epo-cat:hasExternalSpecification property in the epo-cat:item in Catalogue module
Standardised namespace prefix for ePO Model (Note: in the text and diagrams in this report the standardised namespace of epo: has not been used as the standardized namespace is to implemented with all other changes.)
Renaming epo-cat:ItemDescription to epo:ItemProperty.
Replacing epo-ful:hasBaseAmount property with epo:isCalculatedOn in epo-ord:AllowanceChargeInformation and epo-ord:TaxInformation . Replace epo-cat:specifiesItem relationship between epo:Deliverable and epo-cat:Item by inheritance of epo-cat:Item by epo:Deliverable.
epo:Contractor and epo-ord:Seller are the same concepts in a Public Procurement.
epo-ord:AllowanceChargeInformation will have 3 subclasses: epo-ord:AllowanceInformation, epo-ord:ChargeInformation, and epo-ord:PriceDiscountInformation, because epo-ord:AllowanceChargeInformation is an epo-cat:InformationHub, and it is directly connected to the Line and Document.
The VAT rate value will be modeled through epo-ord:TaxInformation epo-cat:hasPercentage and epo-ord:TaxInformation epo-cat:hasTaxCategory. The working group then continued to discuss the points that were seen as contentious previously:

Charge Information - Item Level or Line Level?

During the discussion, participants debated whether the Charge Information should be at the Item level or Line level. To illustrate the point an example of countries where certain charges are associated with food items containing sugar. For instance, if an item is priced at 1 euro, the actual amount paid might be 1.7 euros due to the sugar charge. This charge is applied at the price level.
One suggestion put forward was to have the price at the item level, establishing a direct association between the item and its price. However, after further deliberation, the decision was made to maintain the price at the line level while establishing a reference between the line and the item.

In PEPPOL the price is specified based on the location, and the order reflects the price based on quantities. There are two types of discounts: line-level discounts and price-level discounts. Line-level discounts can be defined as a specific amount per line, such as a discount of 100 euros per line. Price-level discounts, on the other hand, are expressed as a certain amount per unit, such as cents per orange.
As a result of the discussion, it was decided to remove the epo-ord:PriceDiscountInformation element and introduce new associations for enhanced clarity and consistency. The new associations are epo-ord:hasPriceDiscountInformation between epo-cat:Price and epo-ord:isSpecificToOrderLine, as well epo:hasPriceSurchargeInformation between epo-cat:Price and epo-cat:ChargeInformation.

Modeling of Item and Batch IDs

The participants agreed to replace the relation adms:identifier with epo:hasBatchID to improv clarity and consistency. The epo: hasCatalogueItemID is replaced by epo:hasSellerItemID
As part of the discussion, it was agreed to add definitions for all epo:Item and epo:Batch IDs:

epo:hasManufacturerItemID: The general identifier assigned to the concept as defined by the manufacturer.
epo:hasBuyerItemID: The general identifier assigned to the concept as defined by the Buyer.
epo:hasBatchID: The identifier assigned to a specific batch of the produced Item.
epo:hasSellerItemID: The general identifier for the concept as defined by the seller.
epo:hasSerialID: The identifier assigned to the specific instance of the produced concept.

To illustrate these concepts, an example was discussed: when purchasing a new mobile phone, the seller ID and the manufacturer ID may differ, but a generic buyer ID would be used.
Organisation and Person Certificates
It was agreed upon by the participants to introduce the epo:hasCertification relation between epo:Certificate and epo:Organization, epo:Person, and epo:Item. This new relation allows for the association of certifications with these entities.
Furthermore, the definitions for the following concepts were updated as follows:

epo:Certifier: A Role of an Agent that issues a Certificate.
epo:Certificate: Proof of conformance of the instance of the concept to a defined set of criteria, ensuring credibility, trust and transparency.

Remodelling epo-ord:DeliveryTerm

During the working group meeting, it was agreed by the participants to rename the entity epo-ord:DeliveryTerm to epo-ord:DeliveryAgreement. By changing the name of the concept there is no conflict with the Term hierarchy of the ontology and the original modelling can be reused. The update was made directly in the meeting.
.

Revising Definitions

The participants revised the definitions with respect to the concepts that were discussed during the meeting.

epo-ord:DeliveryAgreement: Term applying to the delivery of goods, services and works. Additional Information: Delivery terms identifier can normally be Incoterms accompanied by the description of specific conditions related to the delivery.
epo-cat:InformationHub: Grouping of data that may be associated to various concepts. Additional Information: For example, AllowanceChargeInformation may be associated to the Order or the Catalogue (either at the Line level or at the Document level), amongst others.
epo-cat:ChargeInformation: Information about tax, fee or duty imposed. Additional Information: Charge category indicates the nature of the tax/duty/fee, for example VAT, CAR, etc. Charge category modifier may be used in case different levels, exemptions or other modifications apply. The charge can be fixed or relative to the price.
epo-ord:AllowanceChargeInformation: Information about discounts, taxes, duties and fees imposed.
epo-ord:AllowanceInformation: Information about the discounts imposed.

Action Points:

Remove epo-ord:PriceDiscountInformation and introduce new associations:
epo-cat:Price epo-ord:hasPriceDiscountInformation epo-ord:isSpecificToOrderLine
epo-cat:Price epo:hasPriceSurchargeInformation epo-cat:ChargeInformation.
Update definitions for all epo:Item and epo:Batch IDs
Organisation and Person Certificates:
Update the definition of epo:Certifier and epo:Certificate.
Introduce new associations:
epo:Person epo:hasCertification epo:Certificate
org:Organization epo:hasCertification epo:Certificate
epo:Item epo:hasCertification epo:Certificate

Working Group meeting 04/05/2023

Date: 04/05/2023
Participants: Natalie Muric, Peter Borresen, Thomas Pettersson
Model editor: *Andreea Pasăre
*Note editor: Jana Ahmad

Agenda

Goal: Discuss the current status and any potential improvements/harmonisations needed for the eCatalogue, eFulfilment, and eOrdering modules.

Discuss removing "postAward" objects and considering them as a document.
Also, consider "epo-cat:announcesPostAwardObject."
Revise "epo-cat:hasExternalSpecification" property in the "epo-cat:item" object and consider deleting it since we have added "epo-cat:hasExternalSpecification" association between "epo-cat:Item" and "epo:Document."
Change eCat:Item to epo:Item
Discuss adopting "epo" as a uniform namespace prefix in the ePO model.
Revise the naming of "epo-cat:ItemDescription" to align it between modules.
Discuss aligning VAT and other tax categories between modules.
Propose using "TaxInformation" instead of "hasVATRate" and "hasVATCategory."
What is the difference between TaxInformationSchema and TaxInformation?
Discuss if "epo-ord:PriceDiscountInformation" and "epo-cat:ChargeInformation" are the same and align them across modules.
Propose changing "epo-cat:specifiesItem" to "epo:specifiesDeliverable."
Propose adopting "epo-cat:Deliverable" into all modules.
Discuss the difference between "epo:Contractor" and "epo-ord:Seller" for all modules.
Decide whether "epo:hasSerialID" should be at the Item level or the Batch level.
A party should have authorization. This needs to be modeled. Take into account the Certificate as well.
Discuss epo-ord:TaxInformation definition.
Discuss removing epo-ord:DeliveryTerm.
Discuss the proposal to change epo-cat:ItemDescription to 'epo-cat:ItemProperty
Considering the possibility of moving 'TaxInformation' to 'epo-cat:Item', but further investigation is required
What is the Difference between epo:hasManufacturerItemID and epo:hasSerialID

Discussion:

The participants has approved the removal of the "postAwardObject" class and instead considers "postAward" objects as documents for the eOrdering, eCatalogue, and eFulfilment modules.
The participants approved to Remove "epo-cat:hasExternalSpecification" property in the "epo-cat:item" in Catalogue class
The participants has agreed upon the use of 'epo' as the standardized namespace prefix in the ePO model.
The participants has approved changing from 'epo-cat:ItemDescription' to 'epo:ItemProperty'
The participants approved that "epo:Contractor" and "epo-ord:Seller" are the same for all modules. However, it still needs to be determined how to incorporate this into the model."
epo:hasBatchId, epo:SerialId are different, and they are in Item instances. (TBD 16)

The participants discussed the need for parties to have authorization.
- The relation between person and epo:Certificate should be added

The participants discussed removing if removing epo-ord:DeliveryTerm will affect eFulfulment model.
- epo:hasGeneralDeliveryTerm, epo:hasDeliveryTermDescription properties will be added to epo-ord:DeliveryInformation
- epo:specifiesDeliveryTermLocation relatin will be added between epo-ord:DeliveryInformation and dct:Location

The participants discussed the ReceiptAdvice
There are three type of rejection for recipet
In ReceiptLine livel
In Consignment Delivery Shipment.
TransportHandlingUnit

Action points:

"epo:Contractor" and "epo-ord:Seller" are the same for all modules. However, it still needs to be determined how to incorporate this into the model.
ReceiptAdvice modeling in eFulfilment epic

Working Group meeting 02/05/2023

Date: 02/05/2023
Participants: Natalie Muric, Ivan Willer, Sellitto Giovanni Paolo
Model editor: *Andreea Pasăre
*Note editor: Jana Ahmad

Agenda:

Review Criteria model modifications
Review Channel and Contact Point
Review Place of Performance: GH 364
Review metadata requirements for RDF notices

Discussion:

The WG discussed the Criteria model for standard forms and eforms mappings.

at-voc:applicability codelist has been relocated from epo:ParticipationCondition to epo:Contract.
A model for instantiating selection criteria has been created to map the conditions for participation and conditions related to contract in a standard form.

To ensure that ePO mode meets the requirements for pursuing professional, economic, and technical abilities in the standard form, the epo:ProfessionalSuitabilitySummary, epo:EconomicStandingSummary, and epo:TechnicalAbilitySummary objects have been added to the epo:SelectionCriteriaSummary.
The objects epo:ProfessionalSuitabilitySummary, epo:EconmicStandingSummary, epo:TechnicalAbilitySummary are added to epo:SelectionCriteriaSummary to meet suitability to pursue the professional, economic standing and technical ability requirements in the standard form.
The properties epo:hasSelectionCriteriaStatedInProcurementDocuments and epo:describesMinimumLevelOfStandards have been added to the epo:SelectionCriteriaSummary object to address the economic and financial standing requirements.

The properties epo:describesProfessionRelevantLaw and epo:hasServiceReservedToParticularProfession have been added to the epo:ProfessionalSuitabilitySummary object to provide a list and brief description of the relevant conditions that need to be fulfilled.

The property epo:describesObjectiveParticipationRules has been added to fulfill the objective rules and criteria for participation requirement.
The property epo:describesDepositsAndGuaranteesRequired has been added to address the requirement for deposits and guarantees.

Y2EYhmG4V26jAGsYhmEYZm6jAGsYhmEYZm6jliysIQiCIGhYBFhDEARBUMsFWEMQBEFQywVYQxAEQVDLBVhDEARBUMsFWEMQBEFQywVYQxAEQVDLBVhDEARBUMsFWEMQBEFQywVYQxAEQVDLBVhDEARBUMsFWEMQBEFQywVYQxAEQVDLBVhDEARBUMsFWEMQBEFQywVYQxAEQVDLBVhDEARBUMsFWEMQBEFQywVYQxAEQVDLBVhDEARBUMsFWEMQBEFQywVYQxAEQVDL5cAahmEYhuF2+v8BvMGzjUNiBdUAAAAASUVORK5CYII=

epo:hasPaymentArrangementand epo:hasEPayment properties is in epo:ContractTerm which satisfy main financing conditions and payment arrangements and/or reference to the relevant provisions governing them.
epo:hasOrganisationGroupType is added to epo:ContractTerm to fulfil information abut staff responsible for the performance of the contract.
epo:hasReservedExecution in epo:Contract satisfies the execution of the contract is restricted to framework of sheltered employment programmes

epo:describesDepositsAndGuaranteesRequired and epo:describesVerificationMethod: properties are added to the epo:ParticipationConditionsSummary object to satisfy Qualification for the system requirement.

Working Group meeting 27/04/2023

Date: 27/04/2023
Participants: Natalie Muric, Christian Mondini Consrzio, Ivan Willer, Pietro Palermo, Sellitto Giovanni Paolo, Wim Kok. Thomas Pettersson
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Goal: Discuss the current status and any potential improvements/harmonisations needed for the eCatalogue, eFulfilment, and eOrdering modules.

Discuss removing "postAward" objects and considering them as a document.
Also, consider "epo-cat:announcesPostAwardObject."
Revise "epo-cat:hasExternalSpecification" property in the "epo-cat:item" object and consider deleting it since we have added "epo-cat:hasExternalSpecification" association between "epo-cat:Item" and "epo:Document."
Change eCat:Item to epo:Item
Discuss adopting "epo" as a uniform namespace prefix in the ePO model.
Revise the naming of "epo-cat:ItemDescription" to align it between modules.
Discuss aligning VAT and other tax categories between modules.
Propose using "TaxInformation" instead of "hasVATRate" and "hasVATCategory."
What is the difference between TaxInformationSchema and TaxInformation?
Discuss if "epo-ord:PriceDiscountInformation" and "epo-cat:ChargeInformation" are the same and align them across modules.
Propose changing "epo-cat:specifiesItem" to "epo:specifiesDeliverable."
Propose adopting "epo-cat:Deliverable" into all modules.
Discuss the difference between "epo:Contractor" and "epo-ord:Seller" for all modules.
Decide whether "epo:hasSerialID" should be at the Item level or the Batch level.
A party should have authorization. This needs to be modeled. Take into account the Certificate as well.
Discuss epo-ord:TaxInformation definition.
Discuss removing epo-ord:DeliveryTerm.
Discuss the proposal to change epo-cat:ItemDescription to 'epo-cat:ItemProperty
Considering the possibility of moving 'TaxInformation' to 'epo-cat:Item', but further investigation is required
What is the Difference between epo:hasManufacturerItemID and epo:hasSerialID

Discussion:

The WG has approved the removal of the "postAwardObject" class and instead considers "postAward" objects as documents for the eOrdering, eCatalogue, and eFulfilment modules, at least for now. Further discussion is required for the eOrdering module.
- The proposal is to consider po-ord:OrderResponse as the type of epo-ord:Order, but further discussion is required.
The WG approved to Remove "epo-cat:hasExternalSpecification" property in the "epo-cat:item" in Catalogue class
The WG has agreed upon the use of 'epo' as the standardized namespace prefix in the ePO model.

The WG has approved changing from 'epo-cat:ItemDescription' to 'epo:ItemProperty', but we need to check the inheritance with 'epo-elementDescription'.
Discuss aligning VAT and other tax categories between modules.
- Change the property from "epo-ful:hasBaseAmount" to "epo:isCalculatedOn" in both "epo-ord:AllowanceChargeInformation" and "epo-ord:TaxInformation".

Allowance Charge Information and related information to be discussed later
- epo-ord:AllowanceChargeInformation epo-ord:LineAllowanceInformation, ord:LineChargeInformation at line and header level
- epo-ord:PriceDiscountInformation in price level.

The WG approved that "epo:Contractor" and "epo-ord:Seller" are the same for all modules. However, it still needs to be determined how to incorporate this into the model."

The WG discussed the Difference between epo:hasManufacturerItemID and epo:hasSerialID

Manufacturer Item Id is the Identifier of item in manufacture side.
Serial Id is the Identifier of instance of item.
The WG proposed to have epo:hasBatchId in item instance level.

The WG discussed the need for parties to have authorization.
- The WG has approved the proposal to have a certificate for organizations, but further discussion is needed for Items.
Discuss Removing epo-ord:DeliveryTerm
- We should keep DeliveryTerm in contract
- For eOrdering: we should consider the following diagram
- epo:hasGeneralDeliveryTerm, epo:hasDeliveryTermDescription properties will be added to epo-ord:DeliveryInformation
- epo:specifiesDeliveryTermLocation relatin will be added between epo-ord:DeliveryInformation and dct:Location
- epo-ord:DeliveryTerm needs further discussion.

Action points:

The WG has approved changing from 'epo-cat:ItemDescription' to 'epo:ItemProperty', but we need to check the inheritance with 'epo-elementDescription'.
Change the property from "epo-ful:hasBaseAmount" to "epo:isCalculatedOn" in both "epo-ord:AllowanceChargeInformation" and "epo-ord:TaxInformation".
Create a diagram for Allowance Charge Information and related information
Draw tables for all terms and definitions for Batch, Item, Identifier.

Working Group meeting 25/04/2023

Date: 25/04/2023
Participants: Natalie Muric, Veit Jahns
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Goal: Discuss the current status and any potential improvements/harmonisations needed for the eCatalogue, eFulfilment, and eOrdering modules.

Discuss removing "postAward" objects and considering them as a document.
Also, consider "epo-cat:announcesPostAwardObject."
Revise "epo-cat:hasExternalSpecification" property in the "epo-cat:item" object and consider deleting it since we have added "epo-cat:hasExternalSpecification" association between "epo-cat:Item" and "epo:Document."
Change eCat:Item to epo:Item
Discuss adopting "epo" as a uniform namespace prefix in the ePO model.
Revise the naming of "epo-cat:ItemDescription" to align it between modules.
Discuss aligning VAT and other tax categories between modules.
Propose using "TaxInformation" instead of "hasVATRate" and "hasVATCategory."
What is the difference between TaxInformationSchema and TaxInformation?
Discuss if "epo-ord:PriceDiscountInformation" and "epo-cat:ChargeInformation" are the same and align them across modules.
Propose changing "epo-cat:specifiesItem" to "epo:specifiesDeliverable."
Propose adopting "epo-cat:Deliverable" into all modules.
Discuss the difference between "epo:Contractor" and "epo-ord:Seller" for all modules.
Decide whether "epo:hasSerialID" should be at the Item level or the Batch level.
A party should have authorization. This needs to be modeled. Take into account the Certificate as well.
Discuss epo-ord:TaxInformation definition.
Discuss removing epo-ord:DeliveryTerm.

Discussion:

The WG Discussed removing "postAward" objects and considering them as documents, and also consider removing the 'epo-cat:announcesPostAwardObject' relation in the following modules.
- eNotice
- eOrdering
- eCatalogue
- eFulfilment

txIAcH9iivgBAABOAgIIAAAAAAAIPQIIAAAAAAAIPQIIAAAAAAAIPQIIAAAAAAAIvUcim+sCAAAAAAAQZgQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQev8HU+pY4brTeroAAAAASUVORK5CYII=

The definition of epo-cat:Catalogue is changed to: A Document describing a set of Items offered for purchase that can be processed in an electronic way.
It is noted that Catalogue is part of the Contract
The WG approved to Remove "epo-cat:hasExternalSpecification" property in the "epo-cat:item" in Catalogue class

The WG has agreed upon the use of 'epo' as the standardized namespace prefix in the ePO model.

The WG has proposed a change from 'epo-cat:ItemDescription' to 'epo-cat:ItemProperty'.

UcdpdFAINQAwAAwCDUAAAAMAg1AAAADAHlRtsrHoRAVgAAAABJRU5ErkJggg==

Should we retain both 'epo-cat:ChargeInformation' and 'epo-ord:PriceDiscountInformation', or are they identical in meaning?
- The WG discussed the validity or appropriateness of using "epo-ord:PriceDiscountInformation" in the context of epo-cat:Price level.
  - The WG has agreed to keep 'epo-ord:PriceDiscountInformation' as part of the 'epo-cat:Price' level.
- The WG deliberated on whether epo-cat:ChargeInformation aligns with the "epo-cat:Price" or "epo-cat:Line or epo-cat:Item level components.
  - The WG is considering the possibility of moving 'TaxInformation' to 'epo-cat:Item', but further investigation is required

LhQcEQRBEARBEARBEARBEEr+P56Ja0g4FqdaAAAAAElFTkSuQmCC

The WG has agreed to the proposal of using 'TaxInformation' as an alternative to 'hasVATRate' and 'hasVATCategory'.

The WG has reached an agreement to eliminate 'epo-cat:specifiesItem' between 'epo-cat:Item' and 'epo:Deliverable', and to consider 'epo:Deliverable' as a type of 'epo-cat:Item'.

ViVpFgEAs2f4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLteFLkiRJkiRJyqWxf2Lk8ToXvWdeAAAAAElFTkSuQmCC

The WG discussed the optimal location of 'epo:hasSerialID' at Item or Batch Level.
- The WG has proposed to remove epo:hasSerialID and use epo:hasManufacturerItemID.

qNkjHFuAAAAAFf5jpK1Vsw5zw0AAADgKr33ePbeUWuN1pokSZIkSdK1lVLiBSRS2Dp6OHWhAAAAAElFTkSuQmCC

The definition of epo-ord:TaxInformation is changed to Information about the imposition of mandatory levies required by law.

Action Points:

Replace 'epo-ord:concludesContract' between 'epo:Contract' and 'epo-ord:OrderResponse' with 'epo-ord:implementsContract'.

We need to create a model that encompasses all the documents that form part of the Contract.
Revise 'Deliverable' in the context of eContract

Working Group meeting 11/04/2023

Date: 11/04/2023
Participants: Natalie Muric, Sellitto Giovanni Paolo
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Continue discussing 1st draft of eContract Model with respect to the initial contract information requirements.

To continue from Award of the contract

Discussion

The WG continued to discuss and model the Award of the Contract in the eContract module, specifically in relation to the requirements for initial contract information. Our methodology involves assessing whether the following requirements are already covered by ePO. If they are, the working group will map them to ePO. If they are not covered, they will be implemented as follows. The bullet points represent the initial contract information requirements, while the sub-bullets indicate their mapping to ePO.

Award of the contract

Award identifier:
- adms:identifier of the epo:AwardDecision
Award date
- epo:hasAwardDecisionDate (type is changed to xsd:dateTime)
Award time
- epo:hasAwardDecisionDate (type is changed to xsd:dateTime)

314dlAAAgAAM7N9axKeLcAfLMIMEgGCQABAMEgCCQQJAMEgACAYJAMEgASAYJAAEgwSAYJAAEAwSAIJBAkAwSAAIBgkA4Q1SkiRdawBf+WWwbSf+DwAAAABJRU5ErkJggg==

Winner economic operator
- epo:Winner
Economic operator name
- dct:title on the foaf:Agent
Economic operator identifier
- epo:hasRegistrationCountry from org:Organization to at-voc:country

Documents
- epo:Contract epo:associatedWith epo:Document
Attachment identifier
- adms:identifier on epo:Document
Attachment description code
- At-voc-new:document-type
Attached document
- we do not provide the binary object, only URL (epo:hasAccessURL on the epo:Document)

Deliverable offered
- epo:specifiesDeliverable epo:Item
Deliverable name
- dct:title on the epo:Item
Deliverable description
- dct:description on the epo:Item
Delivered quantity
- epo-cat:hasQuantity from epo:Deliverable to epo:Quantity

v9UEkII6T0AAAAAAADw64CII4SQ31gAAAAAAADg12FkRRwAAAAAAAAAAMAogYgDAAAAAAAAAAAYAog4AAAAAAAAAACAIYCIAwAAAAAAAAAAGAKIOAAAAAAAAAAAgCGAiAMAAAAAAAAAABgCiDgAAAAAAAAAAIAhgIgDAAAAAAAAAAAYAog4AAAAAAAAAACAIYCIAwAAAAAAAAAAGAKIOAAAAAAAAAAAgCGAiAMAAAAAAAAAABgCiDgAAAAAAAAAAIAhgIgDAAAAAAAAAAAYAog4AAAAAAAAAACAIYCIAwAAAAAAAAAAGAKIOAAAAAAAAAAAgCGAiAMAAAAAAAAAABgCiDgAAAAAAAAAAIAhgIgDAAAAAAAAAAAYAog4AAAAAAAAAACAIYCIAwAAAAAAAAAAGAKIOAAAAAAAAAAAgCEQiDhCCCGEEEIIIYQQQsjg8v8Bm7AYG5PqRrMAAAAASUVORK5CYII=

Deliverable total amount:
- epo:hasContractValue relation is created between epo:Contract and epo:MonetaryValue

epo-con:ContractAmendment object is created with:
- epo:emendsContract relation with epo:Contract.
- epo:hasContractAmendmentDate property.
- epo:providesUpdatedContractValue relation with epo:MonetaryValue
- epo:hasContractAmendment relation with epo:Contract

Contract Roles class is created to specify all roles that participant in Contact

Action:

Change xsd:date to xsd:dateTime.
proposal to adopt epo-cat:Deliverable into all modules
What’s the difference between a epo:Contractor and a epo-ord:Seller for all modules?

Working Group meeting 04/04/2023

Date: 04/04/2023
Participants: Natalie Muric, Sellitto Giovanni Paolo
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Present 1st draft of eContract Model

Discussion

The WG revised the order, catalogue, fulfilment modules from the document level perspective.
The WG continued to discuss and model the eContract module, specifically in relation to the requirements for initial contract information. Our methodology involves assessing whether the following requirements are already covered by ePO. If they are, the working group will map them to ePO. If they are not covered, they will be implemented as follows. The bullet points represent the initial contract information requirements, while the sub-bullets indicate their mapping to ePO.

The WG decided to consider Contract as a Document

Legal references:
- epo:haslegalBasis
- epo:hasLegalReferenceDescription is added

Award criterion type:
- epo:Lot specifies Procurement Criterion (epo:specifiesProcurementCriterion) epo:AwardCriterion

Criterion sandbox is created to clarify the relationship between procedure, lot, criterion, at-voc:legal-basis. at-voc:legal-basis, epo:legal-regime are moved to epo:ProcurementObject

N83FejvPnZHbHeeHITkEWAACAqSfIAq378vz5GOrMdMwrL78syAIAADC1BFlgImRRNtspW062i9KsvqnGWEEWAACAaSTIAhOpGu3M6h0AAACYNoIsMJHScGdW5wAAAMC0EWQBAAAAAJaJIAsAAAAAsEwEWQAAAACAZSLIAgAAAAAsE0EWAAAAAGCZCLIAAAAAAMtEkAUAAAAAWCaCLAAAAADAMhFkAQAAAACWiSALAAAAALBMBFkAAAAAgGUiyAIAAAAALBNBFgAAAABgmQiyAAAAAADLRJAFAAAAAFgmgiwAAAAAwDIRZAEAAAAAlokgCwAAAACwTARZAAAAAIBlIsgCAAAAACwTQRYAAAAAYJkIsgAAAAAAy0SQBQAAAABYJrUga4wxxhhjjDHGGGOMMebnnf8PeALKnEIySoMAAAAASUVORK5CYII=

epo:PlannedProcurementPart is not epo:ProcurementObject.
epo:foreseesProcurementObject relation is added between epo:PlannedProcurementPart and epo:ProcurementObject.

Tender identifier
- epo:includesTender from epo:Contract to epo:Tender
- epo:hasLotReference

Tender digest
- epo:hasElectronicDigest relation is created between documents.
Tender signature
- epo:ElectronicSignature object is created with epo:hasElectronicSignature relation to epo:Document.
- dct:description property is added to epo:ElectronicSignature object

Tender total amount:
- epo-ord:hasTotalTaxInclusiveAmount

Tender total tax amount:
- epo-ord:TaxInformation Action:
Map contract, document wrt top level ontology
To move from epo:ProcurementElement the following suggested documents:
- Tender
- AwardDecision
- ReviewObject
Discuss Tender total tax amount and Tender total amount from initial contract information requirements.

Working Group meeting 21/03/2023

Date: 21/03/2023
Participants: Natalie Muric, Wim Kok, Giampaolo Sellitto
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Discuss eContract Model.

Discussion:

WG discussed the eContract model, mainly the initial contract information requirements:

epo-con: announces contract exists between epo:Contract and epo-con:ContractDocument. It was noted that Contract document is not a contract, it is maybe some additional things such as metadata. What is in the contract is in the contract document.

An Excel document is created in sharepoint including Contract related concepts and their definitions.
epo:bindsBuyer relation created between contract and Buyer.
epo:signedByBuyer relation is created between Buyer and contractDocument

MkQIIWUNAAAAwERB1gghZAoDAAAAMFFmrKwBAAAAAADMZpA1AAAAAACAEoKsAQAAAAAAlBBkDQAAAAAAoIQgawAAAAAAACUEWQMAAAAAACghyBoAAAAAAEAJQdYAAAAAAABKCLIGAAAAAABQQpA1AAAAAACAEoKsAQAAAAAAlBBkDQAAAAAAoIQgawAAAAAAACUEWQMAAAAAACghyBoAAAAAAEAJQdYAAAAAAABKCLIGAAAAAABQQpA1AAAAAACAEoKsAQAAAAAAlBBkDQAAAAAAoIQgawAAAAAAACUEWQMAAAAAACghyBoAAAAAAEAJSckaIYQQQgghhJDy5P8DgXtJdNJU2u8AAAAASUVORK5CYII=

WG did a Mapping between Contract model and initial contract information requirements:

Issue date, time and identifies should be in the document
isSubjectToContractSpecificTerm relation is created between contract and ContractTerm

Procurement project type: is contract-nature on ContractTerm
Description of Extension and option: epo:ContractTerm has epo:hasOptionsDescription data property. Duration is considered to be about Options.
Period start date, Period start time: contractTerm defines the contract period.

9OqYBAAABGObfNTf87GqTiRgAJMwHAACQMB8AAEDCfAAAAAnzAQAAJMwHAACQMB8AAEDCfAAAAAnzAQAAJMwHAACQMB8AAEDCfAAAAAnzAQAAJMwHAACQMB8AAEBizYckSZIkvXaPBAAA4MMA6G7xx+EI53QAAAAASUVORK5CYII=

qt-voc:cpvsuppl is removed
CPV: at-voc:cpv enumeration is added.

CPV supplementary: is not included in ePO
Project execution location: epo:ContractTerm defines place of performance which is dct:location

zze2nXfUdus77Bt2nYw2n7b8dOeQFOEQAMAAFDQ99dXO9xtNzafTgWa5AQaAACAojaRZvNJ87vNl4XV2zDOCDR5CTQAAAA7YnjEW92Rk0ADAACwI8aHvNUcOQk0AAAAAMEEGgAAAIBgAg0AAABAMIEGAAAAIJhAAwAAABBMoAEAAAAIJtAAAAAABBNoAAAAAIIJNAAAAADBBBoAAACAYAINAAAAQDCBBgAAACCYQAMAAAAQTKABAAAACCbQAAAAAAQTaAAAAACCCTQAAAAAwQQaAAAAgGACDQAAAEAwgQYAAAAgmEADAAAAEEygAQAAAAgm0AAAAAAE2wo0ZmZmZmZmZmYWsx8jgDZQhaLbbAAAAABJRU5ErkJggg==

Procurement project lot: Contract and lot class is created.

Lot identifier:
- epo:hasTenderReference relation is renamed between contract and tender.
- epo:hasLotReference relation is renamed between contract and lot.

YguADCE9IW2Ma0BAOhHdAEAAACogOgCAAAAUAHRBQAAAKACogsAAABABUQXAAAAgAqILgAAAAAVEF0AAAAAKiC6AAAAAFRAdAEAAACogOgCAAAAUAHRBQAAAKACogsAAABABUQXAAAAgAqILgAAAAAVEF0AAAAAKiC6AAAAAFRAdAEAAACogOgCAAAAUAHRBQAAAKACogsAAABABUQXAAAAgAqILgAAAAAVEF0AAAAAKtAVXYwxxhhjjDHGGGNMORP9H5My6HZhnaeQAAAAAElFTkSuQmCC

Working Group meeting 28/02/2023

Date: 28/02/2023
Participants: Ahmed Abid, Wim Kok, Natalie Muric, Csongor Nyulas, Sellitto Giovanni Paolo
Model editor: Andreea Pasăre, Eugen Costetchi
Note editor: Jana Ahmad

Agenda

Standard form mapping issues (ePO repository):
- GH 370
- GH 431
Continue discussing Procedure and sub-procedure

Discussion

GH 370

To be closed only after we get confirmation that (and perhaps a link to) an issue asking for the introduction of appropriate code(s) in the at-voc:direct-award-justification vocabulary was opened with DG GROW.

GH 431

hasRestatedAwardedValue: This is wrongly modeled and applied in the mappings. It will be updated in the context of modeling eContract. To be discussed in RDF meeting

Procedure and sub-procedure:

WG decided to:
- Separate a procedure from its scope
- Drop down plan into its phases.
Notes from WG:
- Procedure itself is a plan.
- It is not correct to use process concept to refer to plan/procedure.
- Nothing is to be executed in procedure, it is just a plan
- Lot is referring to purpose.
Plan hierarchy model
- Lot is procurementScope not a ProcurementObject

SelectioCriteria and ExclusionGround are specified for LotQualificationPhase

Lot Plan composition model contains the phases/stages of procurement lifecycle

Overall plan composition model

Note, if we have hundreds of lots and anything is applied to one lot it will be applied to all lots in the same procedure (to be discussed later).
We should find a better term than LotPreAwardLifecycle/Workflow.

Working Group meeting 07/02/2023

Date: 07/02/2023
Participants: Jana Ahmad, Natalie Muric, Csongor Nyulas
Model editor: Andreea Pasăre
Note editor: Eugeniu Costetchi

Agenda

Standard form mappings - ePO GitHub issues:
- GH 422 Missing fields F21, IV.2.5, IV.2.9
Procedure/Sub-procedure

Discussion

GH 442

In the context of concession contracts, the award of procedure actually means procedure. So the “scheduled date for start of award of procedure” is the start of the procedure. We should look into the Directive 2014/24/EU for a better understanding.

kGQFQEJNz8nPl87H35Xvry2RWdYOsa90vdTVpaaht1o0mFA28AK9FeCO8RdoTOYwBwnxAZwKtBPEkFQFhoLz+Z8LHYRP9IiBDqEPO+6QhEgHhiERAJAJCEYmA7IhEQHZEIqAzIhFwcEQiIDvCRIB7ER7tpbu8pU4ckk1N0lwv8sIHNfLZvCLpGsuTr+TnyFP7D0jePpEDuz+UmtY2Id5fUZ9WEcD3ZCcRQP143rDdJzj1RcCJQCQCwhGJgHAciQj4f1HoSUhCBZdkAAAAAElFTkSuQmCC

Procedure versus sub-procedure

The term procedure has been conflated.
Question: What is a procedure?
Answer: A description of steps taken by someone, a plan.
This plan acts as a general plan for multiple Lots. There are specific plans per each Lot, but the general plan should be fine-tuned in order to cover all the Lots.

Within a procurement project we can have a procedure type. Each lot should be executed once or multiple times according to the procedure type.

There are procedural things that are open to all Lots. We can think about it as a procurement procedure.

Some actions/events are reusable within a procedure:

Buyer calls for competition [object] (publish Competition Notice)
Buyer awards [object] (and publish a Contract Award Notice)
Buyer (re-)opens a (mini-)competition [object]

The negotiation action can be part of the competition.

Also, WG discussed re-usable process fragments:

Qualification (exclusion grounds and selection criteria)
Competition

eAuction and mini competitions are subsets of closed competition.

Some important examples of procedure types are discussed:

Restricted procedure:
- Buyer calls for competition [specific-object] (Competition Notice)
- Qualification
- Closed-Competition [specific-object]
- Buyer awards [specific-object] (Contract Award Notice)
Restricted procedure with eAuction
Restricted procedure with Dynamic Purchasing System

The competition is related to award criteria and the qualification is related to exclusion grounds and selection criteria. All the process fragments should take into consideration the criteria and the appropriate objects.

Plan versus execution

A differentiation between a plan and an execution is discussed.

A Plan (~Procedure + Lots) is a detailed proposal for doing or achieving something.
- Goal: award of a contract
An *Execution (~ProcedureExecution) *represents the carrying out of a plan, order or course of actions.
- Achievement: award of a specific contract.
- We can have procedure executions per Lot (for a Lot there may be one or multiple executions)

We can have procedure-executions per Lot. For a lot, there may be one or multiple executions.

There is one execution for the whole procedure.

Each lot has one or multiple procedure executions within the “frame” of the “Procedure” execution.

Procurement purpose is split into Lots, and NOT the procedure that is split into lots.

Working Group meeting 31/01/2023

Date: 31/01/2023
Participants: Jana Ahmad, Laszlo Ketszeri, Natalie Muric, Csongor Nyulas, Giampaolo Sellito, Marc Christopher
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

Discuss the Candidate role
- https://github.com/OP-TED/ePO/issues/174
Standard form mappings - ePO GitHub issues:
- ePO GH 421
- ePO GH 422
- ePO GH 424
- ePO GH 408
- Mapping GH 331
- Mapping GH 332

Discussion

 The WG discussed:
Candidate role: This role exists in ePO version 2.0.2 as epo:CandidateShortList have the following definition: “The tenderers that have been selected in a two stage procedure.

Additional information: the types of procedures that this shortlist applies to are restricted procedures, competitive procedures with negotiation, competitive dialogue procedures and innovation partnerships. The WG approved the previous definition and additional information on (WG 27/07/2018).

epo:EconomicOperatorShortList is a superclass for CandidateShortList. This concept has the following definition: “The Economic Operators that are considered for a given procedure”. The WG approved the previous definition on (WG 22/08/2019).

A new role was added for the next ePO release, epo:Candidate, with the following definition: “The role of an agent that has expressed interest to participate in a competition. The WG approved the previous on (WG 31/01/2023).

The concept is a subclass of epo:OfferingParty as depicted in the diagram below:

S6V5eu0PpfGwYYpAAAA+kKYAgAAIAJhCgAAgAiEKQAAACIQpgAAAIhAmAIAACACYQoAAIAIhCkAAAAiEKYAAACIQJgCAAAgAmEKAACACIQpAAAAIhCmAAAAiECYAgAAIAJhCgAAgAiEKQAAACIQpgAAAIhAmAIAACACYQoAAIAIhCkAAAAiEKYAAACIQJgCAAAgAmEKAACACPbC1MzMzMys5f4GOexIC6835HUAAAAASUVORK5CYII=

Buyer role refinement: The buyer may need to be further refined into AwardingBuyer and AcquiringBuyer, similarly as it is done for the CPB.

GH 421:

Section III.1.* of F21 refers to Selection criteria.

Section III.1.4: Objective rules and criteria for participation refers to description in requirement.

Codelist to be used in at-voc-applicability.
epo:hasreservedProcrument added to ParticipationCondition.

epo:hasReservedExcution added to ContractTerm Section III.2. *“contract performance conditions” refers to ContractTerms.

PMUZ5VdCXgeiFC8T6n1dbi3T0f4qpZMkckqaYXcD6EVn4DgC3fDscsySJsY5LcYy8W5YWSlWvwo7lvKG+TivGInNThNLrZUvocl+BdYdRN4cd0ciQAAAABJRU5ErkJggg==

In the eForms they are at the Lot level, but in the standard forms they are at the Procedure level? They are in fact “criteria summaries” for Procedure level

Section III.2.1: information about a particular profession refers to ContractTerms

564EHAIYZeAAIZOABIJCBB4BABh4AAhl4AAhk4AEgkIEHgEAGHgACGXgACGTgASCQgQeAQAYeAAIZeAAIZOABIJCBB4BABh4AAhl4AAhk4AEgkIEHgEAGHgACGXgACGTgASBQb+AlSVJGj4EHALJcATl+tXZ9p8jJAAAAAElFTkSuQmCC

information about a particular profession should be mapped to selection criteria summary:
In selectionCriteriasummary object two properties are added
Eop:hasProfessionRelevantLaw
epo:isReservedToParticularProfession

BT-79 - III.2.3 - information about staff responsible for the performance of the contract
isResponsibleStaffNameIsrequired property is created in ProcrumentCriteriasummary object

Two enumerations are added to SelectionCriterien object

EGcYZmSD1kMIA0BB2f8hzjDMyAathxAGAABAIRHCAAAAKCRCGAAAAIVECAMAAKCQCGEAAAAUEiEMAACAQiKEAQAAUEiEMAAAAAqJEAYAAEAhEcIAAAAoJEIYAAAAhUQIAwAAoJAIYQAAABQSIQwAAIBCIoQBAABQSIQwAAAACokQBgAAQCERwgAAACgkQhgAAACFRAgDAACgkAhhAAAAFBIhDAAAgEKKhTDDMAzDMAzDFGrsOgYAAACK4P8DGGgQKQ6Ki9kAAAAASUVORK5CYII=

epo:hasPerformingStaffQualificationInformation is added to epo:ProcurementCriterien

Question: Does SelectioncriteriaSummary inherit from SelectionCriterien?

Yes, So then, ProcrumentCriteriaSummary inherits from ProcrumentCriterien.
To be checked, when reworking on the Criteria & Criteria Summary: if epo:isReservedToParticularProfession: is the same as the one in the epo:ContractTerm.

Working Group meeting 24/01/2023

Date: 24/01/2023
Participants: Jana Ahmad, Laszlo Ketszeri,, Natalie Muric, Csongor Nyulas, Giampaolo Sellito
Model editor: Andreea Pasăre
Note editor: Eugeniu Costetchi

Agenda

Discuss github following issues:

Standard form mappings - TED-SWS github issues:
- GH 119
Standard form mappings - ePO github issues:
- GH 418
- GH 419
- GH 420

Discussion

GH 119

When we have missing mapping in the technical mapping but the data exists in the standard forms, then we should add the remark in the RDF output as a rdfs:comment. ==== GH 418
The generalisation statement between a role and its type (AcquiringParty, SellerParty or AuxiliaryParty) should not be present in the technical mapping.
This ticket and https://github.com/OP-TED/ted-rdf-mapping/issues/289 were closed, with the same resolution.

GH 419

The property epo:hasLotAwardLimit has been deleted.

epo:hasMaximumNumberOfLotsToBeAwarded is kept.

GH 420

In the standard form, we have just generalised information (generalisation criterion) at the procedure level.
And the procurement criteria is specified for the lot level .
In the standard form, procedure specifies criteria summary (so we can have summary criterion at the procedure level .).
We should differentiate between criteria and criteria summary
Create participation criterion class in a lot level (so we have 4 criteria now).
Participation is at the submission level.
Participation conditions should be even before submission
Two approaches for Criteria modelling (concept and instance diagrams) have been presented and are depicted below.

Example 1

w7EgibL+4XIAQAAABSCyAEAAAAUgsgBAAAAFILIAQAAABSCyAEAAAAUgsgBAAAAFILIAQAAABSCyAEAAAAUgsgBAAAAFILIAQAAABSCyAEAAAAUgsgBAAAAFILIAQAAABSCyAEAAAAUwifLC09Co9Wnh4tXBgAAAMgLkQMAAAAoBJEDAAAAKASRAwAAACgEkQMAAAAohI4iRzwWAAAAIC9EDgAAAKAQRA4AAACgEEQOAAAAoBBEDgAAAKAQRA4AAACgEEQOAAAAoBBEDgAAAKAQRA4AAACgEEQOAAAAoBBEDgAAAKAQRA4AAACgEEQOAAAAoBBEDgAAAKAQRA4AAACgEEQOAAAAoBD+H4fyFIxTZr5jAAAAAElFTkSuQmCC

Example 2

Submission terms:
- Submission terms: rules for submission
- Submission terms has participation condition
- Participation conditions had reserved procurement.

hHAAAAEgIwjkAAACQEIRzAAAAICEI5wAAAECCEM4BAACAhCCcAwAAAAlBOAcAAAAS4n9cFkMmx2ncXgAAAABJRU5ErkJggg==

PamR385hDfvdQlRteclSay5helviHCO3HCKMI7vNANopN7G5vYYfX1WA1WgTxo2ySIG5SudziQXBYGlkUl45YOJJCXuclf9b27ZIM7q0tY399RUUV+b3ELfWOIrG6ROVqQb2fqN5RXOao9SxJojawjVES9xePfoygcrdLn3dWaLuKaIciittUjraoDG0teo846nJKUsiDIW3MukkQWRQ92OAld0UVSRS+MP8XtSKteqKGCrgAAAAASUVORK5CYII=

Create criteria summary diagram to differentiate between procurement criteria and procurement criteria summary:
- If the procurement criteria goes to the procurement object, Ground exclusion is the same for all lots.
- Giampaolo suggests adding relation between Selection Criteria and Selection Criteria Summary (aggregation relation).
Decided to model the following:

+3YMQ0AIBAAMfwbJCF5LTCwnIgONVGAEOcAAAAAABDiHAAAAAAAQpwDAAAAAECIcwAAAAAAiDVnXwAAAAAA4BPnAAAAAAAQ4hwAAAAAAEKcAwAAAABAiHMAAAAAAAhxDgAAAAAAIc4BAAAAACAemscyA9xzysoAAAAASUVORK5CYII=

Working Group meeting 17/01/2023

Date: 17/01/2023
Participants: Jana Ahmad, Natalie Muric, Pietro Palermo, Thomas Pettersson, Giampaolo Sellito, Emidio Stani, Ivan Willer
Model editor: Andreea Pasăre
Note editor: Eugeniu Costetchi

Agenda

Core Vocabularies alignment
- observations for ePO
- Core Business
- CPOV
eOrdering

Discussion

Org ontology link: https://www.w3.org/TR/vocab-org/

Core Vocabularies observations

epo:hasOrganisationUnit should be an attribute on the OrganisationalUnit concept from org ontology.
If we follow org ontology we need to add a new class where to put only an attribute for the name.

vwghhMQmNKgJIYQQQgghhBBCCCGEzAg0qAkhhBBCCCGEEEIIIYTMCDSoCSGEEEIIIYQQQgghhMwINKgJIYQQQgghhBBCCCGEzAg0qAkhhBBCCCGEEEIIIYTMCDSoCSGEEEIIIYQQQgghhMwINKgJIYQQQgghhBBCCCGEzAg0qAkhhBBCCCGEEEIIIYTMCDSoCSGEEEIIIYQQQgghhMwINKgJIYQQQgghhBBCCCGEzAg0qAkhhBBCCCGEEEIIIYTMCDSoCSGEEEIIIYQQQgghhMwINKgJIYQQQgghhBBCCCGEzAg0qAkhhBBCCCGEEEIIIYTMCP8PVFhkCPTdwgcAAAAASUVORK5CYII=

The reason why we conflated these two is the case when only a particular unit is the Buyer.
Recommendation to not separate these two concepts (Organisation and Organisation Unit) and only rename the attribute to epo:hasOrganisationUnitName
- Why? Because the Agent that takes a role (e.g. Buyer) can be a Unit or an organisation, but we decided to set the description at the “organisation level”.
epo:hasLegalFormType - from SEMIC perspective we asked the OP to create the Core Vocabulary for the classification of the legal forms from GLEIF:
- This will be published in the future.
- Switch to using a code list for legal type classifications.

cv:LegalEntity versus epo:Business

Definition for cv:LegalEntity:
A self-empoyed person, company, or organization that has legal rights and obligations.

QvHjpz8SADDJIpUPQKdeSLbb+PGoc8SP8xYAgOktUvnwPE++rqTnRQEpahvitFdLCRdfAGB6i1Q+AADADwDlAwAAaEX5AAAAWlE+AACAVpQPAACgFeUDAABoRfkAAABaUT4AAIBWlA8AAKAV5QMAAGhF+QAAAFpRPgAAgFaUDwAAoBXlAwAAaEX5AAAAWlE+AACAVpQPAACgFeUDAABoRfkAAABaUT4AAIBWlA8AAKAV5QMAAGhF+QAAAFpRPgAAgFaUDwAAoBXlAwAAaEX5AAAAWlE+AACAVpQPAACgFeUDAABoRfkAAABaUT4AAIBWlA8AAKAV5QMAAGhF+QAAAFpRPgAAgFaUDwAAoBXlAwAAaEX5AAAAWlE+AACAVpQPAACgFeUDAABoRfkAAABaUT4AAIBWlA8AAKAV5QMAAGhF+QAAAFpRPgAAgFZvUj7OnTsny0dw8j1ydwAAADBBt9sVbcGyLNklgtgsRmRi+UgkEq7r2rYtRnlEfPOAyQ8AADBZvGpcuHBBFAnf9x3HiT1kcvmQbUUSnaPZbMa+CAAAMJ7neUHYQkSXkJddRkwsH5cvX5YbrVYrOmiaZrQNAAAwQjSPXq8n+4ecyHBdd9qZj0Qikc1mo135LIIPAAAwQdQcjo6OLl68KPpDtH4jMrF8iLaSSqXOKX4EAAAwwfnz52VhuHTpUiKRqNVqQWwK47hjxHfiHMfpdDrxI9ElHAAAgLGiX5UVDMN4VSNiJpaP4GS1h23b8hdmgvCyzfceAQAAoBAVIuoM9Xr9+188tXwAAAC8dZQPAACgFeUDAABoRfkAAABaUT4AAIBW3wH6TmFMOlTauAAAAABJRU5ErkJggg==

Definition for epo:Business:
A private law company registered in a national registry.

epo:Business should be a subclass of cv:LegalEntity in Core Business Vocabulary.
In order to align with Core Voc, it means we need to add cv:LegalEntity and org:FormalOrganization between org:Organization and epo:Business.
But a Business has to be a FormalOrganization.
In CPOV, a PublicOrganisation is not org:FormalOrganisation, but it is directly under org:Organisation.

Depending on the country, a cpov:PublicOrganisation may have a legal entity, so it may be a formal organisation.
Hierarchy
- Org:Organisation
  - cv:PublicOrganisation
  - org:FormalOrganisation
    
    legal:LegalEntity (self-employed person, company, or organisation with certain rights)
    
    Action: Replace epo:Business by cv:LegalEntity
  - epo:OrganisationGroup
We need to have a discussion on whether the legal form type is at the legal entity level or at the organisation level.
- What if we have the case when a tenderer is a public organisation?
This relationship is used at the Organisation level because foaf:Agent includes also a person or a system.
Decided to remove the relation from epo:OfferingParty to epo:Business as depicted in the diagram above.

Checking on whether we had a formal organisation in older versions of ePO 2.0.1 and it was not.
But in 12th May 2020 WGM minutes it appears to have been created an epo:FormalOrganization concept: https://docs.ted.europa.eu/epo-wgm/notes/2020-05-12-wgm.html

Concession contract

In CPSV-AP the cv:ServiceConcessionContract was added as a subclass of epo:ConcessionContract:

WCeQt0dpNt2GHT8UIso+CrVjketBr100+lEAjiIYzCBmEUDr7vvwlNieF+bgseAAAAAElFTkSuQmCC

For CPSV-AP we need a relationship between epo:Contract to epo:ContractSpecificTerm (epo:hasContractTerm) in order to be able to get to the at-voc:contract-nature:

Contract includes specific terms
Contract cannot have epo:ContractSpecificterms
Contract “includes Lot”, is not right, needs more discussion on this.

Order

Look into the syntax binding, where we will see all the “elements” that we need to see in the order.
For example, Contract ID, is missing, or what is in the Buyer? It is hard to see all the elements from the ePOcore or eCatalogue, or eFulfillment.
Request: can we have a plain table with all properties for a class (including inherited attributes).
- Technical Question:
  - Given a UML model, can we generate an “application profile” in a tabular representation (see SKOS-AP-EU ), for each class considering also inheritance.
  - Can we also automatically generate a “Path” to get that property?
It was found that a epo:ProcurementElement does not have an identifier, so the relation between epo:ProcurementObject and epo:Identifier was moved from epo:ProcurementElement to epo:Identifier as depicted in the diagram below:

Proposal to work on a table that contains all the properties for all the concepts in the Order phase on the 26th Jan.

Working Group meeting 10/01/2023

Date: 10/01/2023
Participants: Jana Ahmad, Vladimir Alexiev, Emiel Dhondt, Juris Kalejs, Wim Kok, Natalie Muric, Giampaolo Sellito, Emidio Stani
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

Core Vocabularies alignment
- observations for ePO

Discussion

Core Vocabularies observations

cpv:Person

data type is Changed from rdfs:Literal to rdf:langString in the following properties :
- foaf:name
- foaf:familyname
- foaf:givenName
- person:patronymicName
- dct:alternative
cv:deathDate Removed from cpv:Person.

cpov:ContactPoint

epo:hasInternetAddress is similar to contactPage with foaf:Document as range.
Proposal by Core Vocabularies to change the range to anyURI so this contactPage can be adapted by ePO as well.
Based on the standard forms, epo:hasInternetAddress is probably the URL of the Organization and not of the ContactPoint.

https://schema.org/mainEntityOfPage
Proposal to add epo:hasHomePage (xsd:anyURI, [0..*]) as an attribute on org:Organization concept with the following definition: “The main web page.”

cv:Channel

epo:hasDescription is similar to http://purl.org/dc/terms/description
If we change the datatype to LangString, we need to change them all.
rdfs:Literal allows integers, booleans and LangString, etc.
We need to revise data types and make them more specific.
Better to use rdf:PlainLiteral, see GitHub ticket: https://github.com/OP-TED/ePO/issues/405
Instead of epo:hasDescription switch dct:description.
epo:hasURL is mandatory property, but it should not be, because sometimes we might need to use epo:isAdhocChannel.
In standard forms AdhocChannel is not a boolean, but in eForms it is.
The AdhocChannel should not be CommunicationMean.
An Organization hasCommunicationMeans either a Channel or a DeliveryGateway.

epo:AgentInRole

The attribute epo:hasTitle was changed to dct:title and the definition modified accordingly.

epo:Identifier

WG discussed whether to use dct:identifier instead of epo:hasID.
But dct:identifier has a range of rdfs:Literal and can not be used.
We need to decide on whether to change to adms:identifier (old github issue: https://github.com/OP-TED/ePO/issues/258)
If we need more properties for ePO we should add a ticket to adms.

PSXdAFwygm2+8THFfROdBrjt8SHH9sAdjWhb+f0i4c7+rH638DmWMEupwuqTgAAAAASUVORK5CYII=

euBusinessGraph Semantic Data Model

https://docs.google.com/document/d/1dhMOTlIOC6dOK_jksJRX0CB-GIRoiYY6fWtCnZArUhU/edit#
Presenting the reg org vocabulary: https://www.w3.org/TR/vocab-regorg/

pg111kJEXfh15AClteTmzQiNFvbYabXSq+OzS6vjqUDtdp0Fmrrw68gBGq0m31PHM4Ha7ToLDHXh15EDNFpNvqeOZwK123UWGOrCryMHaLSafE8dzwRqt+ssMNSFX0cO0Gg1+Z46ngnUbtdZYKgLv44coNFq8j11PBOo3a6zwFAXfh05QKPV5Hvq0KEjO+jCryMHqEW1IFCHDh3Z4f8Boy4TvokJvsUAAAAASUVORK5CYII=

dct:Location

locn:geographicName data type is Changed from rdfs:Literal to rdf:langString.

locn:Address

All attributes data types are changed from rdfs:Literal to rdf:langString, except locn:postCode and locn:locatorDesignator.

CCCEV

On cccev:Requirement:

cccev:description changed to dct:description (rdf:PlainLiteral).
cccev:identifier changed to dct:identifier.
We need to use an identifier for requirements.
To stay consistent to how identification is realised in ePO, we switched to using adms:identifier instead of dct:identifier as per CCCEV requirement.
Instead of cccev:name we will use skos:prefLabel (rdf:PlainLiteral).
There should be only one description and we added as additional information that we can have multiple languages for the same description. (see https://www.w3.org/TR/skos-reference/#L1567)

On cccev:type changed to dct:type
On cccev:InformationConcept, hasDescription and hasTitle are changed to dct:description and skos:prefLabel.

WG disscussed the Channel

In standard form we have the following section for communication:

We want to use the AdhocChannel as a URL and not a boolean.
We might need to remove epo:hasAdditionalInformation and epo:hasName from cv:Channel.
In CPVS-AP, cpsv:PublicService has a cv:Channel.
We need to do a comparison to version ePO 2.0.1.
Adding epo:hasToolsAccessURL (xsd:anyURI, [0..1]) attribute to epo:AccessTerm concept with the following definition: “Web page where the tools and devices for electronic communication that are not generally available can be downloaded free of charge.”
This needs to be further discussed.
cv:Channel was moved from org:Organization level to epo:AgentInRole level.

In PEPPOL, an endpoint is an identifier.
The cv:Channel class was deleted.
We need to further discuss the difference between epo:Business and cv:LegalEntity.

Any comments on the documentation?

Click here to let us know

Cumulative content of Working Group Meetings in 2023

Working Group Meeting

Agenda:

Discussion

Action Points

Working Group meeting

Agenda

Discussion

Definitions:

Action Point

Working Group meeting

Agenda:

Discussion:

Working Group meeting

Agenda:

Discussion:

ePO module harmonisation

Contract

Action Points

Working Group meeting 30/05/2023

Agenda

Discussion

Framework Agreement

DPS:

Relation and property definition harmonisation.

Working Group meeting 23/05/2023

Agenda

Discussion

Framework Agreement

DPS

Award Decision:

Definitions:

Action points:

Working Group meeting 16/05/2023

Agenda

Discussion

Charge Information - Item Level or Line Level?

Modeling of Item and Batch IDs

Remodelling epo-ord:DeliveryTerm

Revising Definitions

Working Group meeting

Agenda:

Discussion:

Action point:

Working Group meeting

Agenda:

Discussion:

Working Group meeting

Agenda:

Discussion:

ePO module harmonisation

Contract

Action Points

Working Group meeting 30/05/2023

Agenda

Discussion

Framework Agreement

DPS:

Relation and property definition harmonisation.

Working Group meeting 23/05/2023

Agenda

Discussion

Framework Agreement

DPS

Award Decision:

Definitions:

Action points:

Working Group meeting 16/05/2023

Agenda

Discussion

Charge Information - Item Level or Line Level?

Modeling of Item and Batch IDs

Remodelling epo-ord:DeliveryTerm

Revising Definitions

Working Group meeting 04/05/2023

Agenda

Discussion:

Working Group meeting 02/05/2023

Agenda:

Discussion: